Windows NT как операционная система реального времени

NT–многонитевая ОС и позволяет вытеснение и тем самым удовлетворяет требованию 1 (§1.1).

В Windows NT имеются два класса приоритетов: класс реального времени и динамический класс. Процессы в классе реального времени имеют фиксированный приоритет, менять который может лишь само приложение, тогда как приоритет процессов динамического класса может меняться диспетчером. Процесс имеет базовый уровень приоритета. Нить в процессе может иметь приоритет в диапазоне плюс/минус 2 около базового уровня или один из двух крайних уровней класса (16 или 31 для реального времени). Например, нить в процессе с базовым уровнем 24 может иметь приоритет 16, 22 - 26, 31. Очевидно, что гарантировать предсказуемость системы можно только при использовании процессов первого класса.

Малое число возможных уровней препятствует реализации СРВ на базе NT. Большинство современных ОС РВ позволяет иметь по крайней мере 256 различных уровней. Чем больше имеется уровней, тем более предсказуемо поведение системы. В Windows NT имеется только 7 различных уровней для нити в данном процессе. В результате многие нити будут выполняться с одинаковыми приоритетами и, как следствие, предсказуемость поведения системы будет посредственной. Более того, общее число уровней для всех процессов класса только 16, и положение не спасает даже замена нитей процессами, не говоря уже о том, что переключение контекста для процессов снижает производительность.

В ОС РВ вызовы системы синхронизации (семафоры или критические секции) должны уметь управлять наследованием приоритетов. В Windows NT это невозможно, поэтому требование 4 не удовлетворяется.

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

Предсказуемость системных вызовов Win32 API. Если компьютер искусственно загрузить обращениями к диску и сетевой обработкой, то задержки возрастают до нескольких миллисекунд. Win32 API очень богат, но не предназначен для реального времени. Например, запросы mutex обрабатываются в порядке поступления, а не в порядке приоритетов, что снижает предсказуемость. Для синхронизации нитей в одном процессе критические секции следует предпочесть всем другим способам (этот вызов затрачивает всего несколько мкс по сравнению с 35 мкс на вызов mutex).

Несмотря на все достоинства API, ядро и менеджер ввода/вывода Windows NT недостаточно приспособлены к обработке событий реального времени на уровне приложений.

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

Прерывания обрабатываются в два этапа. Сначала выполняется очень короткая программа обслуживания прерываний (Interrupt Service Routine, ISR). Впоследствии работа завершается выполнением DPC (Deferred Procedure Call) – процедуры отложенного вызова. Возникает следующий поток событий:

· происходит прерывание;

· процессор сохраняет PC, SP и вызывает диспетчер;

· ОС сохраняет контекст и вызывает ISR;

· в ISR выполняется критическая работа (чтение/запись аппаратных регистров);

· DPC ставится в очередь FIFO;

· ОС восстанавливает контекст;

· процессор восстанавливает PC, SP;

· ожидающие в очереди DPC выполняются на уровне приоритета DISPATCH_LEVEL;

· после завершения всех DPC ОС переходит к выполнению приложений.

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

Отделение DPC от ISR позволяет уменьшить время маскирования прерывания. Это позволяет быстро откликнуться на аппаратуру для срочных вещей, таких, как чтение регистра. Но когда DPC установлен в очередь с порядком FIFO , нет никакой гарантии по времени, что пройдет до того, как DPC будет запущен. Это уменьшает предсказуемость системы и делает не пригодным для RTOS. ISR может быть вытеснена другим ISR с более высоким приоритетом, а DPC имеет более высокий приоритет, чем пользовательские и системные нити. Но поскольку все DPC имеют одинаковый уровень приоритета и ISR должна быть сведена к минимуму, ваш DPC будет вынужден ждать остальных драйверов устройств непредсказуемым образом.

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

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

· число приоритетов реального времени слишком мало для СРВ;

· не решена проблема инверсии приоритетов (для процессов класса реального времени);

· для встраиваемых приложений слишком велики требования по памяти и слишком дорога массовая лицензия;

· драйверы устройств имеют очень медленные DPC и не допускают прерываний другими DPC.

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

· загрузка CPU низка (DPC имеют достаточно времени);

· критическая работа (или даже вся) делается на уровне DPC или (еще лучше) на уровне ISR. В таком случае непонятно, зачем вообще нужна ОС.

Но для жесткой СРВ использование Windows NT невозможно – СРВ никогда не будет предсказуемой. Для перевода Windows NT в класс жестких СРВ необходимо:

a) класс процессов реального времени должен иметь больше уровней;

б) решить проблему инверсии приоритетов;

в) время, затрачиваемое каждым системным вызовом, должно быть предсказуемо и известно;

г) система прерываний должна быть заменена целиком:

· DPC должны иметь много уровней приоритетов;

· DPC должны быть вытесняемыми более приоритетными DPC;

· драйверы от третьих фирм и системные драйверы должны быть настраиваемыми (уровни прерываний ISR, уровни прерываний DPC);

· драйверы от третьих фирм должны быть открыты для разработчиков, должно быть известно по крайней мере максимальное время, затрачиваемое на работу ISR и DPC;

· должно быть известно время маскирования прерываний.

Существуют разные варианты использования технологии NT для разработки СРВ:

· использование NT на верхнем уровне систем автоматизации;

· использование NT как она есть для построения мягкой СРВ;

· реализация API-интерфейса Win32 над другой ОС РВ;

· совместная работа на одном процессоре NT и другой ОС РВ (или ее части);

· разработка приложений жесткого реального времени;

· использование мультипроцессорной архитектуры, когда NT выполняется на одном процессоре (или более), а часть реального времени – на остальных.

Использование Windows NT на "верхнем" уровне систем автоматизации. Этот метод лежит в основе одной из типовых конфигураций современных комплексов реального времени. Суть его в том, чтобы разнести функции HMI/SCADA и функции реального времени по разным уровням иерархии системы. Контроллеры нижнего уровня, работающие с объектным вводом/выводом и оснащенные ОС РВ, передают данные для отображения и т.д. на компьютеры c NT, расположенные на более высоком уровне. В этом случае непосредственно к NT требования реального времени, как правило, не предъявляются, поскольку это прерогатива нижнего уровня.

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

Использование NTв системах мягкого реального времени.Windows NT содержит в себе элементы реального времени, классы приоритетов реального времени и эффективную систему обработки прерываний. Учитывая эти особенности и ограниченно используя некоторые средства (например GUI), можно применять эту ОС для построения приложений мягкого реального времени. Единственный способ сделать это – перехватить прерывание, для чего необходимо добавить специальное аппаратное расширение. LP-Elektronik, например, перехватывает прерывание и использует затем NMI (немаскируемое прерывание, не используемое на уровне NT) для обработки событий реального времени. Этот подход применим тогда, когда процессор имеет отдельный стек прерываний, что дает минимальную задержку прерывания, но требует дополнительной аппаратуры.

Реализация API-интерфейса Win32 над другой ОС РВ. Главным преимуществом Windows NT является интерфейс прикладного программирования Win32 API. У него много объектов синхронизации. Данный подход уже осуществлен в некоторых ОС РВ (VxWorks). Преимущество этого подхода в том, что API-интерфейс WIN32 опирается в данном случае на полностью предсказуемое и надежное ядро ОС РВ. Добавление Win32 API к ОС, предназначенной для обработки в реальном времени, избавляет от необходимости модифицировать HAL. Преимущества такого подхода:

· имеется переносимость;

· небольшой след;

· поведение ОС РВ известно.

Недостатки:

· нельзя использовать стандартные приложения NT;

· невозможно смешивание с драйверами устройств NT, поэтому весь мир коммуникаций NT недоступен;

· другие драйверы графических устройств и приложения NT невозможно или трудно использовать;

· ограничена возможность расширения в будущем;

· необходимо использовать специальные средства разработки и компиляторы.

Среди коммерческих реализаций этого подхода – QNX и VxWorks, использующие библиотеку Willows.

Разработка приложений жесткого реального времени. В принципе можно создать полностью предсказуемое приложение в стандартной chtlt NT, обратив внимание на процедуры загрузки и "закрытия" системы и на взаимодействие с другими процессами.

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

· модификация HAL c перехватом прерываний и включением небольшого диспетчера или ОС РВ;

· выполнение NT как одной из задач над (супервизором) ОС РВ.

Модификации ядра. Только этот подход способен превратить Windows NT в настоящую ОС РВ с сохранением большинства ее возможностей. Однако исходные тексты ядра Windows NT недоступны для третьих фирм – это одно из положений политики Microsoft.

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

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

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

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

Недостатки:

· отсутствует переносимость между реальным временем и средой NT, за исключением случая, когда RT-API разработан на базе Win32;

· драйверы устройств NT нельзя использовать в части реального времени;

· среда разработки усложняется, если для задач реального времени требуется отдельная среда;

· может быть много уровней задач и поэтому много уровней определений контекста. Переключение этих контекстов требует времени.

Известны коммерческие реализации подхода, не требующего модификации аппаратуры: IMAGINATION с HyperKERNEL; RADISYS с комбинацией iRMX/NT; VenturCom с RTX, KPX и RTAPI.

В реализации фирмы RadiSys ОС РВ iRMX работает как первичная ОС, загружающая Windows NT в качестве низкоприоритетной задачи. Пользователь работает только с NT, не видя и не чувствуя iRMX. Все управляющие функции выполняются как высокоприоритетные задачи iRMX, изолированные в памяти от приложений и драйверов NT. Используя функции защиты памяти внутри процессора Intel, Windows NT защищена от задач реального времени.

Комбинация iRMX/NT преодолела трудности, которые возникают при модификации HAL и оставляют пользователя уязвимым при сбоях жесткого диска, сбоях драйверов и системных сбоях NT ("голубой экран смерти"). В этом решении управляющая программа в случае краха NT может либо продолжить нормальное выполнение, либо произвести правильное закрытие системы (shutdown).

Реализация фирмы VenturCom состоит из двух этапов. На первом – мягкая реализация RTX 3.1 содержит интерфейс прикладной программы реального времени RTAPI, который дает время реакции 1-5 мск. RTAPI 1.0 работает со стандартным NT. Единственное изменение, обеспечивающее лучшую синхронизацию событий реального времени, внесено в часы. Так как в Windows NT имеются некоторые плохо предсказуемые процессы, то RTAPI позволит построить только мягкую СРВ с небольшим временем отклика, но недостаточно предсказуемую. Впрочем, большую часть непредсказуемости NT можно устранить, ограничив доступ к системному диску и сети.

Чтобы сделать NT более предсказуемой, необходимо прерывать ее внутренние задачи. В основе второй жесткой реализации RTX 4.1 лежит модификация HAL. В обеспечении детерминизма важную роль играют программируемые часы. В каждый тик часов - аппаратное прерывание с регулярными интервалами времени - предпочтение отдается задаче реального времени. Оставшееся время предоставляется процессам NT, в том числе и процессам мягкого реального времени. Чем чаще тикают часы, тем больше возможностей у процессора для выполнения задач реального времени. Необходимо добиться баланса между многими факторами: частота тиков, время, выделенное для обработки в реальном времени, время, выделенное для выполнения задач NT.

Использование многопроцессорной архитектуры. NT выполняется на одной группе процессоров, а часть реального времени – на другой. Возможно применение архитектур параллельной шины с VMEbus, PCI, PMC или архитектур последовательной шины с Ethernet. Если необходимо, подсистемы могут быть связаны механизмом IPC и процедурами удаленного вызова. Преимущества такого решения:

· нет модификаций каждой ОС;

· можно применять в больших сложных системах;

· для каждой подсистемы можно выбрать свою, наиболее подходящую ОС РВ;

· можно использовать имеющиеся среды разработки.

Недостатки:

· высокая стоимость;

· поведение в реальном времени зависит от поведения канала межпроцессорной связи. Поведение прерываний на шине в таких структурах предсказуемо лишь при хорошей организации.

Для решения проблемы инверсии приоритетов вся система прерываний должна быть перестроена:

· использование DPC для увеличения количества приоритетных уровней;

· приоритеты DPC должны быть абсолютными, а не относительными;

· драйверы от третьих поставщиков и драйверы устройств должны быть конфигурируемыми (напр., по приоритетному уровню ISR и DPC);

· драйверы от третьих поставщиков должны быть документированы, по меньшей мере нужно знать сколько времени тратит драйвер на отработку ISR и DPC;

· время, в течение которого ОС маскирует прерывание, также должно быть известно разработчику;

· время исполнения каждого системного вызова должно быть доведено до сведения разработчика.