QNX: Золушка в семье UNIX

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

Не читатели, которые занимались компьютерными технологиями еще 6-10 лет назад ногда с удивлением спрашивают друг друга: - Куда же все подевалось ? Кто из них не помнит серию IBM-360/370 с OS/360, VM/SP или серию DEC PDP-11 с RSX-11M, или VAX ? Те, кто в свое время успел прослушать классические курсы по операционным системам вдруг с недоумением обнаружили, что все это кажется никому не нужно, поскольку новинка под названием MS-DOS совершила своеобразную революцию, начав историю развития универсальных ОС ‘от Адама’, повторяя уже известные ошибки своих предшественниц. Свежеиспеченные компьютерные газеты и журналы начали неутомимо и настойчиво внушать всем кто их читает что ‘нет компьютера кроме PC и MS-DOS пророк его’, хотя уже давно существовали Apple, MacIntosh, UNIX и многое другое (в том числе QNX).

Как же так получилось? Вероятно, сначала это было связано с обычными для нашей страны перекосами - как в свое время все дружно перешли на ЕС ЭВМ, так же в этот раз на IBM/PC. Потом, когда наступило ‘золотое время’ компьютерного бизнеса, действовали экономические причины - IBM/PC были досттаточно дешевы для массового потребления, а MS-DOS достаточно проста для самостоятельного изучения.

В в этом не было бы ничего плохого, если бы не один важный побочный эффект. Экспансия IBM/PC и MS-DOS привела к появлению целого поколения ‘специалистов-самородков’, никогда не видевших ничего другого и ‘не ведающих что творят’. Каждый, кто смог нарисовать окошко в системе типа Clarion стал называть себя программистом, потом эти программисты стали употреблять термин СУБД по отношению к штучкам типа dBase и даже Btrieve (как будто никогда не существовали IMS, IDMS или DB/2), наконец появились Windows и NetWare и эти люди почувствовали потребность в самореализации. К этому времени потенциальные клиенты созрели для автоматизации и конечно, вся страна неизбежно заболела Novell’ом и Clipper’ом. Мы не хотим принизить достоинства этих систем, но нелишне было-бы вспомнить, для задач какого класса они предназначены. Проблема же заключается в том, что их стали пытаться использовать везде где вообще можно вести речь об автоматизации. Вероятно, практически все банки и страховые компании прошли через этот этап, поскольку представляли собой первую очевидную мишень для автоматизаторов.

К счастью, уже около года как стали заметны признаки повсеместного выздоровления, хотя для многих это стоило больших денег и времени, потраченых впустую. Крупные промышленные предприятия, банки и биржи, телефонные и транспортные компании стали обращать свой взор на альтернативные решения, которые давно и успешно используются в развитых странах, где явление IBM/PC народу хотя и вызвало определенные сдвиги на рынке компьютерных технологий, но не привело к массовому беспамятству. Просто на этом рынке выделился сегмент который стали называть SOHO (Small Office/Home Office) и IBM/PC стал доминирующей аппаратной платформой в этом сегменте, а MS-DOS и MS-Windows - программной платформой.

Тем временем, в секторах банкоских и промышленных приложений утвердились UNIX-системы на базе рабочих станций или мини-компьютеров и лишь в последнее время - на базе IBM/PC. До нас же это не доходило в силу того, что фирмы-производители не предпрнимали усилий по продвижению подобных систем на наш рынок ввиду его отсутствия до последнего времени. Кроме того такие системы недешевы, а их установка и обслуживание требуют определенной квалификации, что препятствовало их импорту отечественными компаниями. Однако, ситуация довольно быстро меняется и уже многие крупные производители техники и программного обеспечения обратили взор на восток.

В связи с этим появились и соответствующие публикации в прессе, посвященные технологиям открытых систем, что постепенно приводит к заполнению образовавшегося вакуума информации. Однако, процесс этот идет все-же довольно медленно и информация касается в основном продукции тех фирм, которые вкладывают зпачительные средства в рекламу в нашей прессе. Это уже привело к тому, что распределение рынка между различными вариантами системы UNIX у нас отличается от среднемирового. Что же касается сектора приложений реального времени, который частично пересекается с секторами банковских и промышленных приложений, но имеет ряд специфических особенностей, то информации о соответствующих системах почти нет, за исключением единичных публикаций. Некоторую известность получили пока лишь VxWorks и Interactive Unix.

Операционная система QNX о которой пойдет речь дальше пока известна лишь сравнительно узкому кругу специалистов а общедоступная информация о ней присутствует пока только в телеконференциях сети Relcom (comp.os.qnx). В обзорах, посвященных UNIX-системам QNX практически никогда не упоминается на том основании что это ‘не совсем UNIX’ (а с архитектурной точки зрения ‘совсем не UNIX’). Тем не менее, при ближайшем рассмотрении оказывается, что по многим параметрам ей нет равных в своем классе, а по наличию стандартного сервиса она постепенно все более приближается к универсальным ОС и в принципе может стать для них очень сильным конкурентом. Но, обо всем по порядку.

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

Прежде всего, проясним смысл выражения ‘реальный масштаб времени’. Типичный пример представляет собой задачу управления вращающимся радиолокатором. Очевидно, что программа управления должна успевать обрабатывать поступающую от антенны информацию быстрее чем она может вращаться, иначе данные будут теряься. Банальное для решение с буферизацией применяемое в обычных системах принципиально неприемлемо (даже при наличии памяти неограниченного объема) поскольку информация поступающая от локатора привязана ко времени и устаревает уже через один оборот антенны. Представьте, что произойдет если система управления начнет буферизовать данные о двух самолетах которым угрожает столкновение. Кстати, задачи подобного типа тоже имеют специфическое наименование - критические приложения (mission-critical applications). Их общая черта - неприемлемо высокая цена сбоя или отказа оборудования.

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

Очевидно, что первым обязательным требованием к архитектуре ОС является многозадачность в истинном смысле этого слова. Варианты с псевдо-многозадачностью типа MS-Windows или Novell NetWare неприемлемы поскольку они допускают возможность блокировки или даже полного развала системы одним неправильно работающим процессом. Для предотвращения блокировок ОС должна использовать квантование времени (то есть принудительную а не добровольную многозадачность), что является достаточно легкой задачей. Вторая проблема (надежность) может быть эффективно решена при полном использовании возможностей процессоров Intel 80386 и старше, что предполагает работу ОС в 32-х разрядном режиме процессора. Для эффективного обслуживания прерываний ОС должна использовать алгоритм диспетчеризации, обеспечивающий вытесняющее планирование, основанное на приоритетах. Кроме того, необходима эффектитвная поддержка сетевых коммуникаций, и взаимодействия между процессами, поскольку реальные технологические системы обычно управляются целым комплексом компьютеров и/или процессов. Весьма желательно также, чтобы ОС поддерживала множественные нити управления, а также симметричную мультипроцессорность.

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

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

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

В упрощенном виде эта последовательность представлена на рис. 1. Очевидно, что время T int зависит от содержания обработки прерывания, в то время как остальные времена зависят от архитектуры и реализации операционной системы. Как правило, для них выполняется соотношение T sl > T il > T iret. Кроме того, ОС определяет еще один характерный интервал, называемый временем переключения контекста. Этот интервал определяет как часто каждый из активных процессов может получать управление при заданных параметрах квантования времени и обычно он примерно на 20% больше чем Т sl. Таким образом мы можем указать четыре временных параметра, определяющих ‘реактивные’ характеристики ОС. Разумеется эти характеристики зависят также от аппаратуры, но при проведении сравнительных испытаний выясняется, что при равных аппаратных условиях эти характеристики (и соответствующие параметры) могут очень сильно различаться у разных операционных систем причем в тех случаях, когда различия очень велики основная их причина заключается не в эффективности реализации а в архитектурных различиях. Не случайно фирма QSSL использует для рекламы ОС QNX девиз ‘Архитектура определяет разницу’. Итак, мы подошли наконец к основному предмету данной статьи - обзору и анализу операционной системы реального времени QNX.

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

Архитектурные принципы

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

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

Размер микроядра в QNX составляет всего около 10 Kb и оно отвечает только за диспетчеризацию процессов, передачу сообщений, переадресацию прерываний и поддержку сетевого интерфейса.

Поддерживается диспетчеризация до 300 процессов с 32 уровнями приоритетов и 4 алгоритма планирования: FIFO, Round-Robin (карусель), Adaptive и Message-Priority.

Отвечает за создание и удаление процессов, управление памятью, таймеры и эмуляцию сопроцессора а также диагностику. Сертифицирован по стандарту POSIX 1003.1 и поддерживает многие расширения POSIX 1003.4. Существует в двух вариантах - 16-ти разрядная версия и 32-х разрядная. Последняя способна исполнять как 16-ти так и 32-х разрядные приложения одновременно, для этого требуется лишь установка двух соответствующих разделяемых системных библиотек (таким образом вы факттически имеете 2 операционные системы в одной упаковке). Кроме того эта версия использует все возможности прцессорв Intel для аппаратной защити памяти, в том числе механизм страниц. Своппинг на диск не поддерживается по приципиальным мотивам, поскольку он плохо совместим с требованиями к ОС реального времени (как мы увидим далее, своппинг в QNX не очень то и нужен).

QNX позволяет работать с несколькими файловыми системами одновременно. В стандартный комплект поставки входят менеджеры файловых систем POSIX, DOS (FAT-12, FAT-16, все виды разделов) и ISO9660 ( CD-ROM’s включая расширения Rock Ridge). Файловая система POSIX семантически соответствует UNIX, при этом обеспечивается более высокая надежность (в том числе при отказе питания) и параллелизм в соответствии с POSIX 1003.1 (например винчестер и флоппи-диски могут обслуживаться одновременно).

Эффективно поддерживает байт-ориентированные устройства, позволяя осуществлять обмен со скоростью 115200 baud в мультизадачной среде на любом 386 процессоре. Следует заметить, что использование буферизованных портов (UART) является совершенно необходимым при скоростях выше 2400 baud.

Сетевое взаимодействие является узким местом в большинстве операционных систем и обычно создает значительные проблемы для систем реального времени. Для того чтобы обойти это препятствие разработчики QNX создали собственную специальную сетевую технологию FLEET и соответствующий протокол FTL (FLEET Transport Layer). Этот протокол не базируется ни на одном из распространенных сетевых протоколов типа IPX или NetBios и обладает рядом качеств, которые делают его уникальным. Основные его качества зашифрованы в аббревиатуре FLEET, которая расшифровывается следующим образом: