QNX против расширений реального времени NT
 
Поиск : 
QNX против расширений реального времени NT
 

Realtime расширения Windows NT


Правильный ли это выбор для вашего следующего проекта реального времени ?

Greg Bergsma

Corporate Communication Manager

QNX Software Systems Ltd.

Перевод: И. Лапко

Г. Гладчуна

Введение

После недавнего появления расширений реального времени для Windows NT, многие разработчики, работающие в реальном времени, начали рассматривать возможность применения NT в своих будущих проектах . Легко увидеть, почему. Вместо того , чтобы объединять приложения реального времени и настольные приложения сетью, теперь может показаться, что  разработчики наконец могут интегрировать оба приложения в одной системе, используя один и тот же API.

Однако является ли NT с расширениями реального времени действительно решением для ответственных приложений реального времени ? Давайте рассмотрим те характеристики, к которым мы пришли и ожидаем увидеть у операционной системы реального времени (ОСРВ) - такие как детерминизм, надежность, низкие накладные расходы и возможность переноса исходного текста, и сравним с "NT реального времени".

Детерминизм реального времени

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

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

  • запаздывание прерываний — время от момента возникновения физического прерывания до начала выполнения первой инструкции обработчика прерываний (ISR), написанной пользователем,
  • запаздывание диспетчера — время от момента окончания выполнения последней инструкции пользовательского обработчика прерываний, до момента выполнения первой инструкции процесса, перешедшего в состояние "ready" из за этого прерывания,
  • время переключения контекста — время от момента окончания выполнения последней инструкции одного процесса пользователя до момента начала выполнения первой инструкции следующего пользовательского процесса.

 

Рисунок 1 - Для описания детерминизма операционной системы большинство разработчиков ОС используют на следующие характеристики :

запаздывание прерываний (Til), запаздывание диспетчера (Tsl) и время переключения контекста (Tcs).

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

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

Процессор

Запаздывание прерываний

Запаздывание диспетчера

Переключение контекста

Pentium 200 1.4 2.9 1.2
Pentium 100 1.8 4.7 2.6
486 DX/33 7.5 12.6 8.2

Как обстоят дела с расширениями реального времени для NT? Есть различные цифры, однако те, которые опубликованы для некоторых NT расширений показывают производительность в 10-15 раз более низкую чем данные в таблице.

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

Высокая живучесть и надежность

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

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

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

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

Что такое программный watchdog ? Это процесс , который получает информацию от ОС  о нарушении прав доступа к памяти. Тогда этот процесс принимает интеллектуальное решение о том, как восстановить работоспособность после сбоя.

Аппаратный и программный охранные таймеры.

Для того , что бы понять важность программного охранного таймера , давайте посмотрим, что многие существующие системы используют для восстановления после программных сбоев : аппаратный охранный таймер, присоединенный к линии сброса процессора. Обычно, какой то компонент системного ПО следит за целостностью системы и стробирует аппаратный таймер, пока система "жива". Если аппаратный таймер не будет стробироваться регулярно, по прошествии некоторого времени он выдаст сигнал сброса на процессор. Хорошие новости - система будет восстановлена после программного либо аппаратного зависания. Плохие новости - система должна полностью перезапуститься, что противоречит нашей цели высокой живучести.

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

  • просто перезапустить процесс без остановки всей остальной системы, или

 

  • прервать любые связанные процессы, перевести аппаратуру в "безопасный" ("safe") режим и скоординировано перезапустить связанные процессы, или

 

  • если сбой критический, произвести скоординированный останов всей системы и выдать звуковой сигнал обслуживающему персоналу.

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

Объективный выбор

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

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

Уменьшение вероятности сбоев ядра

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

В архитектурах традиционных ОС эти компоненты работают как часть ядра в режиме ядра (см. рисунок 2). Код, выполняющийся в режиме ядра работает без использования блока защиты памяти MMU. В результате ошибочные указатели, либо выход за пределы массивов могут привести к разрушению ядра системы, от которых может спасти только аппаратный рестарт. Чем больше кода содержится в ядре, тем больше вероятность его разрушения. В Windows NT подобный сбой приводит к разрушению системы, так называемый "голубой экран".

В ОС микроядра, подобной QNX, только программы ядра ( 32 К кода) и обработчики прерываний работают в режиме ядра, что радикально уменьшает вероятность системного сбоя ядра. (см. рисунок 3).

Рисунок 2 - Архитектура традиционной ОС

 

Рисунок 3 - Архитектура QNX с микроядром

Разрушение системы -"Голубой экран"

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

Есть более серьезная проблема: некоторые расширения реального времени NT могут потенциально вносить свой вклад в отказы ядра. Эти расширения непосредственно внедрены в ядро, как обработчики прерываний (ISR) или в уровень абстракции аппаратуры (HAL). В результате вся система реального времени работает в режиме ядра. И так, что же произойдет, если вы обратитесь по не установленному указателю в вашем приложении реального времени ? Вы получите отказ ядра - крах "голубой экран".

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

Техническая поддержка

Предмет программных отказов вызывает другой вопрос : Куда вы будете обращаться за поддержкой в случае возникновения проблем ? В Microsoft или к разработчику расширения реального времени ? Перед тем как вкладывать средства в расширение , вам нужно определиться , кто будет отвечать за предоставление вам технической поддержки в случае возникновения проблем.

Доступ к ресурсам

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

  • файловые системы (жесткие диски, CD-ROM диски и т.п.)
  • коммуникационные порты (последовательные, параллельные, модемы)
  • процессоры
  • коммуникационные шлюзы (например TCP/IP)

Такой распределенный подход значительно повышает живучесть системы : Если устройство отказало на одной из машин, вы можете автоматически перезапустить процесс так, что бы он использовал устройство или даже файловую систему другой машины.

Рассматривая расширение реального времени NT , вам необходимо определить, будет ли разрешен доступ к ресурсам из приложений NT и из приложений реального времени. Например , пусть вашему приложению требуется высокопроизводительный доступ к файловой системе NT. Предоставит ли расширение NT ту функциональность ,которая позволит вам это сделать? Если да, то как оно обеспечит этот доступ ? Делается ли это через HAL ? Если да, то вы не сможете использовать такие механизмы, которые делают NT неприменимым для реального времени ( т.е. вы утратите контроль над приоритетностью отложенных вызовов процедур (Deferred Procedure Calls), инициализированных ISR). Так же, что произойдет, если Microsoft решит внести изменения в уровень абстракций аппаратуры ? Будет ли ваше расширение реального времени продолжать функционировать ?

Все вышеперечисленные вопросы справедливы так же для доступа к коммуникационным шлюзам.

Системные накладные расходы

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

Что касается накладных расходов на память, большинство расширений просто увеличивают без того высокие требования к количеству используемой памяти. Большинство ОСРВ , с другой стороны, могут быть помещены в ПЗУ небольших встраиваемых систем.

Соответствие стандартным интерфейсам API

Для защиты своих инвестиций , многие разработчики стремятся создавать свои приложения так, что бы они были переносимы на другие платформы. Индустриальный стандарт такой как POSIX API возник для того, что бы помочь разработчику достичь этой цели - даже NT предоставляет опцию POSIX. Несмотря на это, широкое распространение операционных систем Microsoft создало дополнительный стандарт de facto: the Win32 API. В ответ некоторые ОСРВ сейчас поддерживают два стандарта : POSIX и Win32.

К сожалению, некоторые расширения реального времени NT не поддерживают ни POSIX ни Win32. Вместо этого они используют API , что противоречит любым вашим целям, касающимся переносимости на другие платформы и независимости от поставщика. Другие расширения предоставляют только Win32 API и поэтому возможно ограничивают функциональность, которую вы хотите реализовать в вашей подсистеме реального времени.

Выводы

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

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

Почитать на эту тему еще.