работа ( по дисциплине “Организация ЭВМ и вычислительных систем”) «Операционные системы реального времени» Министерство образования российской федерации Московский государственный институт электроники и математики (технический институт) Кафедра ИКТ ( по дисциплине “Организация ЭВМ и вычислительных систем”) «Операционные системы реального времени» Выполнила: студентка группы С-35 Ухина О.В. Проверил: Мартиросян С.Т. Москва 2009 Оглавление Введение............................................................................................................................... 3 Поставленные задачи........................................................................................................... 4 Архитектура ОСРВ и требования к ней............................................................................ 5 Практическая часть............................................................................................................ 10 Установка QNX.................................................................................................................. 10 Тест на инверсию приоритетов........................................................................................ 10 Особенности написания кода под QNX.......................................................................... 14 Заключение......................................................................................................................... 17 "Чем меньше заслуга, тем громче похвала " Френсис Бэкон Введение Что такое операционная система реального времени (ОСРВ)? Это ОС, в которой важно не только успешное выполнение программы, но и время, за которое она выполнилась. Главный параметр — время. Отсюда ОС делятся на системы общего назначения и ОС реального времени. Основная задача ОС общего назначения — эффективное распределение ресурсов ЭВМ (таких как процессорное время, оперативная память и т.п.) между несколькими одновременно выполняющимися программами. Такие ОС поставляются с богатым набором прикладных программ (приложений) и имеют развитый графический интерфейс, позволяющий пользователям работать с приложениями, не задумываясь над внутренними механизмами ОС. А ОС реального времени разрабатываются в расчете на наличие внешних источников данных. Основная задача ОСРВ — своевременно обработать запрос, все аспекты функционирования ЭВМ отходят на второй план. Поэтому ОСРВ поставляются в комплекте с разнообразными средствами разработки приложений. Другими словами, покупателями ОСРВ являются не конечный пользователи, а разработчикам, например, специализированных устройств и управляющих систем промышленного назначения, встраиваемого оборудования и систем реального времени, которых ждет нелегкий труд при разработке программ и на которых лежит огромная ответственность. Так же ими могут интересоваться студенты, изучающие компьютерные специальности, преподаватели, практикующие программисты: как рабочий стенд для разработки UNIX совместимых приложений, которые затем могут переноситься в другие ОС. Об особенностях написания кода пойдет речь далее в работе. В системах управления производством компьютеры, работающие в режиме реального времени, собирают данные о промышленном процессе и используют их для управления машинами на фабрике. Часто такие процессы должны удовлетворять жестким временным требованиям. Если автомобиль передвигается по конвейеру, то каждое действие должно быть осуществлено в строго определенный момент времени. Если сварочный робот сварит шов слишком рано или поздно, то нанесет непоправимый вред машине. Если некоторое действие должно произойти в конкретный момент времени (или внутри заданного диапазона времени), мы имеем дело с жесткой системой реального времени. Вообще, система реального времени включает в себя: 1. Прикладное программное обеспечение; 2. Операционную систему реального времени; 3. Аппаратное обеспечение. Чем отличаются ОС жесткого и мягкого времени ? ОС жесткого времени гарантирует выполнение каких-либо действий за определённый интервал времени. А ОС мягкого реального времени, как правило, успевает выполнить заданные действия за заданное время, т. е. ОС мягкого реального времени выполняет задачу с каким-то значением вероятности. ОС жесткого реального времени не допускаю задержки реакции системы, так как это влечет за собой серьезные последствия. Соответственно важна безупречная работа и самой ОС, помимо выполнения ею программ. Современные ОСРВ В данной работе будет рассматриваться ОС QNX (установка, работа и разработка прикладных программ в ней). Немного истории этой ОС... В 1980 году два студента Университета Ватерлоо Гордон Белл и Дэн Додж закончили изучение курса по разработке ОС, в ходе которого они создали основу ядра, способного работать в реальном времени. Затем переехали в город Каната в провинции Онтарио (северная Силиконовая долина Канады) и основали компанию Quantum Software Systems. В 1982 году была выпущена первая версия QNX для платформы Intel 8088. Это одна из самых популярных ОСРВ, помимо VxWorks и Windows CE. POSIX-совместимость POSIX-совместимость — большое преимущество QNX. QNX Neitrino поддерживает: · Простоту переноса и функциональную совместимость приложений между системами, поддерживающими стандарт POSIX, включая Linux и Unix - в большинстве случаев перенос сводится к перекомпиляции и компоновке с библиотеками QNX Neutrino. · Чистоту реализации стека протоколов IP, который получает гибкость прикладной среды открытого стандарта POSIX, снижая риск нарушения авторских прав. · Знакомую среду разработки, позволяющую программистам с опытом работы в UNIX или Linux освоиться в QNX Neutrino практически мгновенно. Поставленные задачи · Исследовать архитектуру и особенности ОСРВ, так как из нее вытекают некоторые проблемы работы системы, например, инверсия приоритетов . · Выявить особенности написании программ: написание драйверов и программирование для GUI(написание кода в PhAB - Photon Application Builder), программирование в сетях. Архитектура ОСРВ и требования к ней ОСРВ бывают нескольких типов архитектур: 1. Монолитная ОС — ОС представляет собой набор модулей, взаимодействующих между собой, которые предоставляют входные интерфейсы для обращений к аппаратуре. Из-за сложного взаимодействия модулей возникает непредсказуемое поведение ОС. 2. Уровневая ОС, например MS-DOS. Прикладные программы в них могут напрямую обращаться к аппаратуре, а не только посредством ядра и резидентных сервисов. Преимущества — быстрый доступ прикладных приложений к аппаратуре, наибольшая предсказуемость по сравнению с монолитными ОС. Недостаток — отсутствие многозадачности. Проблема обработки обработки асинхронных событий сводилась к их буферизации, а затем последовательному опросу и обработке. Но соблюдение критических сроков обслуживания обеспечивалось высоким быстродействием комплекса по сравнению со скоростью протекания внешних процессов. 3. Одна из наиболее эффективных архитектур для построения СРВ является клиент-сервер архитектура. В такой архитектуре выносятся сервисы ОС на уровень пользователя в виде серверов, микроядро является диспетчером сообщений между пользовательскими программами и серверами — системными сервисами. Такая архитектура дает много преимуществ: повышается надежность ОС, так как каждый сервис является самостоятельным приложением, которое легко отладить и отследить ошибки; система лучше масштабируема, так как можно отключать ненужные сервисы, и это не повлияет на ее работоспособность; повышается отказоустойчивость, так каждый модуль может быть перезагружен без перезагрузки системы. QNX имеет клиент-серверную архитектуру. Функциональные требования к ОСРВ Основным требованием к ОС является реализация в ней многозадачности . Такие требования предъявляются и к системам общего назначения, но для ОСРВ предъявляется ряд дополнительных требований, которые определяются обязательным свойством ОСРВ — предсказуемостью. Многозадачность подразумевает параллельное выполнение нескольких действий. На практике реализация многозадачности упирается в совместное использование ресурсов вычислительной системы. Диспетчеризация (scheduling) потоков — распределение ресурсов между несколькими задачами. Главный ресурс для распределения — процессор. В однопроцессорной системе по-настоящему параллельное вычисление невозможно. В многопроцессорной системе тоже возникает проблема разделения ресурсов, причина — одна шина. Поэтому при построении СРВ применяют группы вычислительных комплексов, объединенных общим управлением. Возможность работы с несколькими процессорами в пределах одного вычислительного комплекса и максимально прозрачное взаимодействие в пределах одной локальной сети нескольких комплексов является важной чертой ОСРВ, значительно расширяющей возможности ее применения. Под понятием задачи в ОС могут пониматься потоки и процессы. Процесс обозначает независимый модуль программы или весь исполняемый файл целиком с его адресным пространством, состоянием регистра процессора, счетчиком команд, кодом процедур и функций. Поток является составной частью процесса и обозначает последовательность исполняемого кода. Любой процесс имеет хотя бы один поток, максимальное количество ограничено лишь только оперативной памятью. Потоки одного процесса разделяют его адресное пространство, поэтому они легко могут обмениваться данными и время переключения между потоками меньше, чем переключение и обмен между процессами. Поэтому в задачах реального времени, там где есть параллельно выполняемые задачи, стараются компоновать с использованием максимального количества потоков. Приоритет потока — целочисленное значение, на основании которого ОС принимает решение, когда предоставить потоку время процессора. Количество приоритетов определяется ОС. В QNX их 64, а в VxWorks — 256. Состояния потока Методы диспетчеризации потоков · FIFO ( First In First Out) — Первый Вошел — Первый вышел . Сначала выполняется задача, которая первой вошла в очередь. Она выполняется пока не будет выполнена, либо пока не будет заблокирована в ожидании ресурса или какого-то события. После этого управления передается другой задаче в очереди. Такой механизм применяется, если у задач одинаковый приоритет. · Карусельная многозадачность (round robin). В этом методе диспетчеризации задается константа — квант времени (time slice). Выполнение потока завершается либо при окончании его выполнения, либо при блокировании его в ожидании ресурса, либо при окончании кванта времени. После этого управление передается следующему потоку в очереди. По окончании выполнения последнего потока управление передается первому потоку, находящемуся в состоянии готовности. Т.е. Выполнение каждого потока разбито на последовательность временных циклов. Этот метод присущ для потоков с разным приоритетом. Как происходит передача управления между потоками с разными приоритетами? 1. Если в состояние готовности переходят два потока с разными приоритетами, то процессорное время дается потоку с более высоким приоритетом. Этот метод называется приоритетной многозадачностью . Но у этого метода есть недостаток — некоторые потоки с низким приоритетом могут вообще не получить доступа к процессу. 2. Решение этой проблемы — адаптивная многозадачность. Метод заключается в том, что приоритет потока, не выполняющийся в какой-то период времени, повышается на единицу. Восстановление исходного приоритета происходит после выполнения потока в течении одного кванта времени при блокировании потока. И тем самым при карусельной многозадачности, очередь более приоритетных потоков не может полностью заблокировать выполнение очереди менее приоритетных потоков. 3. В задачах реального времени к методам диспетчеризации предъявляются специфичные требования, так как передача управления потоку должна выполняться за критическое время обслуживания. Этому требованию соответствует вытесняющая приоритетная многозадачность : как только поток с более высоким, чем у активного потока, приоритетом переходит в состояние готовности, активный поток вытесняется и управление передается более приоритетному потоку. Диспетчирезация потоков в QNX. На практике методы комбинируют. И важно, чтобы все потоки укладывались в критическое время обслуживания, тогда система называется диспетчируемой. В 1970 году Лиу и Лейленд предложили математический аппарат «Частотно монотонный анализ» для проверки систем на то, является ли она диспетчируемой, аппарат был принят в качестве стандарта такими организациями как USA Mitre, NASA, Boeing и др. Для организации параллельного вычисления нескольких потоков необходимо разделение потоков по степени важности. Можно выделить потоки жесткого реального времени, мягкого реального времени и потоки не критические ко времени обслуживания. Каждая группа имеет свой уровень приоритетов, а потоки жесткого реального времени должны иметь приоритет еще и внутри группы. Механизмы синхронизации Потокам так же необходимо разделять ресурсы, например переменные в памяти. Для защиты от искажения, вызванного одновременным редактированием одних и тех же данных разными потоками, используются переменные, которые называются объектами синхронизации. Это мютексы, семафоры, события. В задачах реального времени к этим объектам предъявляется специфические требования, так как на них возможны задержки выполнения потоков, поскольку их назначение — блокирование доступа к некоторому разделяемому ресурсу. Проблема, возникающая при блокировании ресурса, - инверсия приоритетов . Э то когда поток высокоприоритетный и низкоприоритетный разделяют общий ресурс, и есть еще один поток, имеющий средний приоритет среди них. Когда высокоприоритетный поток в состоянии готовности, а поток с низким приоритетом активен, и он заблокировал ресурс, то поток с более высоким приоритетом вытеснит с более низким, а ресурс останется заблокирован. И когда высокоприритетному потоку понадобится ресурс, то он сам перейдет в заблокированное состояние. Если в состоянии готовности находится только низкоприоритетный поток, то ничего страшного не произойдет, низкоприориттеный поток освободит заблокированный ресурс и будет вытеснен потоком с более высоким приоритетом. А если в момент блокирования потока с высоким приоритетом в состоянии готовности находится поток со средним приоритетом, то активным станет он, а с низким приоритетом опять будет вытеснен. И получит он управления после выполнения потока со средним приоритетом. И критическое время обслуживания потока с высоким приоритетом будет пропущено. Если это поток жесткого реального времени, то это недопустимо. Защита от нее заключается в наследовании приоритетов . Суть его в наследование низкоприоритетным потоком, захватившим ресурс, приоритета от высокоприоритетного потока, которому ресурс нужен. Есть еще один метод — Протокол Предельного Приоритета. Он заключается в добавлении к стандартным свойствам объектов синхронизации параметра, определяемого максимальным приоритетом потока, которые к объекту обращается. Если параметр установлен, то приоритет потока, который обращается к данном объекту синхронизации, будет увеличен до указанного уровня, и не сможет быть вытеснен никаким потоком, который сможет нуждаться в заблокированном ресурсе. После разблокирования ресурса, приоритет потока понижается до начального уровня, и так получается что-то вроде наследования приоритетов. Микроядро Микроядро — визитная карточка QNX. Защита памяти процессов и связь между ними на основе синхронного обмена сообщениями. Базовые функции ОС вынесены в отдельный модуль, включающий микроядро и менеджер процессов. Микроядро — коммутирующий элемент по сути, шина, обеспечивающая интеграцию других изолированных программных компонентов в единую систему. Практическая часть Установка QNX QNX стоит сразу устанавливать на виртуальную машину. Версия для некоммерческого использования доступна для скачивания на веб-сайте разработчика www.qnx.com. При установке на VirtualBox у меня возникли проблемы, QNX не устанавливался скорее всего по причине отсутствия поддержки процессором виртуализации. Поэтому следующая попытка была поставить QNX на VMware Workstation. Там почти все заработало, но были проблемы с сетью. Установить QNX очень просто, установка заключается практически лишь только в выборе раздела для установки. Устанавливать QNX на жесткий диск в качестве полноценной ОС для работы не имеет смысла. Для разработки программного обеспечения, которое нуждается в реальном времени ( будет работать под управлением QNX) можно использовать модификацию IDE Eclipse — QNX Momentics, или же работать с QNX посредством, используя виртуализацию( Parallels, VMware, VirtualBox XEN). Следует с осторожностью подходить к выбору аппаратного обеспечения для работы проектов под управлением QNX, так для многого оборудования отсутствуют драйвера. Тест на инверсию приоритетов Код программы, написанном на С/С++: #include <stdlib.h> #include <stdio.h> #include <iostream.h> #include <string.h> #include <unistd.h> #include <pthread.h> #include <semaphore.h> const int THRNUM = 3, NCKL = 10, LINOUT = 5, BUFLEN = THRNUM * NCKL + 1; inline void workfun( int n ) { for( long i = 0; i < n; i++ ) double f = sqrt( 1. + sqrt( (double) rand() ) ); }; char buf[ BUFLEN ]; volatile unsigned ind = 0, nfin = 0; long nrep = 1000; bool bmutex = false, bsemaphore = false; static pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER; static sem_t semaphore, semfinal; void *thrfunc( void *p ) { int t = (int)p; if( t != 1 ) { if( bmutex ) pthread_mutex_lock( &mutex ); if( bsemaphore ) sem_wait( &semaphore ); }; struct timespec tv; tv.tv_sec = 0; tv.tv_nsec =(long)( 1e+6 ); sem_trywait( &semfinal ); nanosleep( &tv, &tv ); for( int i = 0; i < NCKL; i++ ) { buf[ ind++ ] = t + '0'; workfun( nrep ); }; if( t != 1 ) { if( bmutex ) pthread_mutex_unlock( &mutex ); if( bsemaphore ) sem_post( &semaphore ); }; if( ++nfin == THRNUM ) sem_post( &semfinal ); }; int main( int argc, char *argv[] ) { cout << "inverse test, QNX API, vers.1.05L" << endl; int c = 0; while( ( c = getopt( argc, argv, "hmst:" ) ) != -1 ) switch( c ) { case 'h': cout << "\t" << argv[ 0 ] << " [ h | { m | s } | t = value ]" << endl; exit( EXIT_SUCCESS ); case 'm': bmutex = true; break; case 's': bsemaphore = true; break; case 't': nrep = 1; for( int i = 0; i < atoi( optarg ); i++ ) nrep *= 10; break; default: exit( EXIT_FAILURE ); }; sem_init( &semaphore, 0, 1 ); cout << "repeating number = " << nrep; // << ", debug level = " << ndebug; if( bmutex ) cout << ", lock on mutex"; if( bsemaphore ) cout << ", lock on semaphore"; cout << endl; struct sched_param param; int polisy; pthread_getschedparam( pthread_self(), &polisy, &param ); pthread_attr_t attr; for( int i = 0; i < THRNUM; i++ ) { pthread_attr_init( &attr ); pthread_attr_setdetachstate( &attr, PTHREAD_CREATE_DETACHED ); pthread_attr_setinheritsched( &attr, PTHREAD_EXPLICIT_SCHED ); pthread_attr_setschedpolicy( &attr, SCHED_RR ); attr.param.sched_priority = param.sched_priority + i + 1; pthread_create( NULL, &attr, &thrfunc, (void*)i ); }; sem_init( &semfinal, 0, 0 ); sem_wait( &semfinal ); buf[ ind ] = '\0'; cout << buf << endl; exit( EXIT_SUCCESS ); }; Скомпилируем и запустим его на QNX. Вот вывод программы: repeating number = 100000, debug level = 1 2[13:13] 2[13:13] 2[13:13] 2[13:13] 2[13:13] 2[13:13] 2[13:13] 2[13:13] 2[13:13] 2[13:13] 1[12:12] 1[12:12] 1[12:12] 1[12:12] 1[12:12] 1[12:12] 1[12:12] 1[12:12] 1[12:12] 1[12:12] 0[11:11] 0[11:11] 0[11:11] 0[11:11] 0[11:11] 0[11:11] 0[11:11] 0[11:11] 0[11:11] 0[11:11] repeating number = 100000, debug level = 1, lock on mutex 0[11:13] 0[11:13] 0[11:13] 0[11:13] 0[11:13] 0[11:13] 0[11:13] 0[11:13] 0[11:13] 0[11:13] 1[12:12] 2[13:13] 2[13:13] 2[13:13] 2[13:13] 2[13:13] 2[13:13] 2[13:13] 2[13:13] 2[13:13] 2[13:13] 1[12:12] 1[12:12] 1[12:12] 1[12:12] 1[12:12] 1[12:12] 1[12:12] 1[12:12] 1[12:12] repeating number = 100000, debug level = 1, lock on semaphore 1[12:12] 1[12:12] 1[12:12] 1[12:12] 1[12:12] 1[12:12] 1[12:12] 1[12:12] 1[12:12] 1[12:12] 0[11:11] 0[11:11] 0[11:11] 0[11:11] 0[11:11] 0[11:11] 0[11:11] 0[11:11] 0[11:11] 0[11:11] 2[13:13] 2[13:13] 2[13:13] 2[13:13] 2[13:13] 2[13:13] 2[13:13] 2[13:13] 2[13:13] 2[13:13] Тестовые потоки запускаются с приоритетами 11, 12, 13, а запускающий поток имеет приоритет 10. В первом случае нет взаимного блокирования потоков. Все потоки выполняются в такой последовательности 2-1-0 в соответствии со своими статическими приоритетами, указанными перед выполнением. А динамиеский приоритет равен статическому. Во втором случае — взаимное блокирование на мютексе. Поток 0 начинает выполняться, «почувствовав» блокирование со стороны 2, под приоритетом ожидающего потока 2 ([11:13]), вытесняет поток 1. Затем, освободив мютекс, передает управлению потоку 2, после его завершения потоку 1. это наследование приоритетов, препятствующее возникновению инверсии приоритетов. В третьем случае - блокирование на семафоре. Здесь потоки выполняются в таком порядке: 1-0-3 — это инверсия приоритетов. А вот краткий вывод того же самого: repeating number = 100000, debug level = 1 222222222211111111110000000000 repeating number = 100000, debug level = 1, lock on mutex 000000000012222222222111111111 repeating number = 100000, debug level = 1, lock on semaphore 111111111100000000002222222222 Теперь если запустить немного измененный код этой программы для Windows, то получим следующее: repeating number = 500000, no priority 210021021021012211020021220101 repeating number = 500000 011111111110002222222222000000 repeating number = 500000, lock on mutex 000000000022222222221111111111 Как ни странно в Windows, не должно быть принято никаких мр по защите от инверсии приоритетов, так как она не ориентирована на realtime поведение, но в третьем случае мы видим отчетливое наследование приоритетов при блокирование на мютексе. А в первом случае наблюдаются перебои ( там потоки равного приоритета) в отличие от QNX. Особенности написания кода под QNX Драйверы В случае ОС реального времени для встраиваемого оборудования необходимость написания драйверов — обычное дело. Поэтому разработчики QNX (фирма QSSL) создали беспрецедентную по своей простоте — технологию создания драйверов. Это если сравнивать с техникой драйверов в системах: OS-360 — IBM/360; MS-DOS; Windows 95/98; Linux x86. Почему такую технологию удалось создать в QNX? Ответ — все дело в микроядре. ОС QNX построена на редко реализуемой в ОС концепции — коммутации сообщений. Ядро ОС при этом выступает в качестве компактного коммутатора сообщений между взаимодействующими программными компонентами. Все запросы, обслуживаемые драйвером, предусматриваемые POSIX ( open(), read()...), реально же посылаются драйверу (менеджеру ресурса) в виде сообщений уровня микроядра. Код сообщения определяет тип операции, а последующее тело сообщения — конкретные параметры запроса, зависящие от типа операции. ( в этой технике могут обрабатываться и сообщения произвольных, не специфицированных системой типов, несущих в себе любой пользовательский каприз). Вот порядок взаимодействия: В этой ОС все запросы API пакуются в тело сообщений, а микроядро системы обеспечивает их синхронизацию и доставку от отправителя к получателю. Для любых взаимодействий в ОС имеется единый механизм передачи, приема и обработки запросов, однако в других семействах ОС такого нет. Из этого понятно, что: · любой драйвер (менеджер ресурса) в этой логической модели рассматривается, как сервер некоторой услуги (ресурса), предоставляющий сервис клиентам — пользовательским приложениям; · драйвер теперь выглядит как и заурядное приложение в системе, а значит может загружаться и выгружаться динамически; · ОС становится защищенной от ошибок функционирования драйверов, как и от задачи пользовательского уровня — они работают в разных кольцах аппаратной защиты памяти; · возможность динамически выгружать и загружать драйвера — путь к построению систем высокой живучести; · драйвер может быть написан на С/С++; · обеспечивается полная переносимость исходного кода; · единообразно и автоматически обеспечиваются механизмы синхронизации в ОС на низшем уровне синхронизации сообщений микроядром; · огромный плюс: драйвер-сервер совершенно одинаково обслуживает запросы клиентов как со своего компьютера, так и с любого другого по сети QNET (сетевая система QNX) Программирование для GUI PhAB — Photon Application Builder, который включается в дистрибутивы QNX, по сути не является IDE в привычном смысле: он не содержит редактор исходного кода, символьного отладчика, не генерирует даже проект, в отличие от Borland C++ Builder, MS Visual C++, например. Это скорее строитель GUI-образов приложения: PhAB избавляет разработчика от рутины по отслеживанию размеров, цветов и прочего, и позволяет привязать обрабатывающий код к GUI-событиям. Весь же программный код реакции на события разработчик прописывает традиционными методами на C/C++. Вот рабочий стол построителя: Программирование в сетях Для ОС QNX существует специфичная утилита on, аналога которой нет в других операционных системах. Это своеобразная надстройка над интерпретатором shell. Можно сказать, что это сетевое расширение интерпретатора. Существуют очень много способов удаленного запуска процессов и обмена данными между ними. В QNX создана своя собственная, отличная от IP сеть. Сеть QNX настолько прозрачна, что использование механизмов, подобных тем, что имеются в других ОС, в ней не требуется. Процессы «общаются» друг с другом посредством сообщений микроядра, причем находятся они на одном компьютере, или на разных — не имеет значения. Эта утилита позволяет: 1. Запускать процессы на удаленном узле QNX сети; 2. Запускать процессы с удаленного узла QNX сети; 3. Запускать процессы с установленным фиксированным уровнем приоритета (1-63); 4. Запускать процессы на другом терминале (перенаправление ввода/вывода и установка управляющего терминала); 5. Запускать процессы от имени другого пользователя (при наличии привилегий администратора); 6. Останавливать процесс сразу после запуска для отладочных целей. Это позволяет присоединить к процессу отладчик и продолжить его выполнение вручную. Заключение В работе было проведено исследование ОСРВ на примере QNX Neutrino, архитектура, диспетчеризация потоков, защита от инверсии приоритетов, т.е. основные требования к ОСРВ. Так же выявлены некоторые особенности написания прикладных программ под QNX. ОСРВ — специфичная система, к которой предъявляется множество требований. От них зависит правильность и своевременность выполнения задач. Важно, чтобы она отвечала этим требованиям.