Операционные системы реального времени windows

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

1. «Жесткие» и «мягкие» системы реального времени

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

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

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

В зависимости от отношения к опозданиям системы реального времени делятся на «жесткие» (hard) и «мягкие» (soft).

В жесткой системе:

• опоздания не допускаются ни при каких обстоятельствах;
• в случае опоздания результаты обработки уже никому не нужны;
• опоздание считается катастрофическим сбоем;
• стоимость опоздания бесконечно велика.

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

В мягкой системе реального времени:

• повышается стоимость опоздания;
• допускается низкая производительность в случае опоздания.

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

Итак, разница между жесткой и мягкой системами зависит от предъявляемых к ним требований. Система называется жесткой, если «система не должна опаздывать никогда», и мягкой, если «система не должна опаздывать, как правило».

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

2. Удовлетворяет ли Windows NT требованиям, предъявляемым к ОС РВ?

2.1. Нити и приоритеты

Очевидно, что NT — многонитевая ОС, она позволяет вытеснение и тем самым удовлетворяет требованию 1 (см. врезку).

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

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

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

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

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

2.2. Предсказуемость системных вызовов Win32 API

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

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

2.3. Управление прерываниями в NT

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

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

• Происходит прерывание.
• Процессор сохраняет PC, SP и вызывает диспетчер.
• ОС сохраняет контекст и вызывает ISR.
• В ISR выполняется критическая работа (чтение/запись аппаратных регистров).
• DPC ставится в очередь.
• ОС восстанавливает контекст.
• Процессор восстанавливает PC, SP.
• Ожидающие в очереди DPC выполняются на уровне приоритета DISPATCH_LEVEL.
• После завершения всех DPC ОС переходит к выполнению приложений.

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

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

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

2.4. Управление памятью в NT

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

3. Может ли Windows NT использоваться в качестве ОС РВ?

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

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

Но для жесткой СРВ использование Windows NT невозможно — система реального времени никогда не будет предсказуемой.Что следует изменить в Windows NT, чтобы ее можно было использовать в жестких СРВ?

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

б) Необходимо решить проблему инверсии приоритетов.

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

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

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

Готовы ли разработчики Microsoft ввести эти усовершенствования в NT или они полагают, что рынок слишком мал, и оставят его свободным для третьих фирм?

4. Коммерческие решения, расширяющие NT возможностями обработки в реальном времени

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

• Использование NT как она есть для построения мягкой системы реального времени.
• Реализация Win32 API над другой ОС РВ.
• Совместная работа на одном процессоре NT и другой ОС РВ (или ее части).
• Использование мультипроцессорной архитектуры, когда NT выполняется на одном процессоре (или более), а часть реального времени — на остальных.

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

Также возможен перехват HAL посредством трюков с процессором Intel. Однако это можно реализовать только на платформе Intel. Механизмы перехвата посредством обработки исключительных ситуаций на уровне устройства поглощают определенную вычислительную мощность.

4.1. Использование NT как таковой

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

Иногда вводят усовершенствования в механизм обработки прерываний. Единственный способ сделать это — перехватить прерывание, для чего необходимо добавить специальное аппаратное расширение. LP-Elektronik, например, перехватывает прерывание и использует затем NMI (немаскируемое прерывание, не используемое на уровне NT) для обработки событий реального времени. Этот подход применим только тогда, когда процессор имеет отдельный стек прерываний. Программа NMI должна быть написана аккуратно: в ней нельзя использовать вызовы ОС и она должна быть как можно короче, чтобы не потерять другие прерывания. Такое решение дает минимальную задержку прерывания, но требует дополнительной аппаратуры. Как и в других решениях, здесь необходим дополнительный механизм связи между NT и частью реального времени. Разница в том, что при этом требуется большая аккуратность в использовании NMI.

4.2. Реализация Win32 API над другой ОС РВ

Добавление Win32 API к ОС, предназначенной для обработки в реальном времени, избавляет от необходимости модифицировать HAL или использовать другие трюки с NT. Преимущества такого подхода:

• имеется переносимость,
• небольшой след,
• поведение ОС РВ известно.

Недостатки:

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

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

4.3. Совместная работа на одном процессоре NT и ОС РВ

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

• модификация HAL c перехватом прерываний и включением небольшого диспетчера или ОС РВ;
• выполнение NT, как одной из задач над (супервизором) ОС РВ.

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

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

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

Задачи реального времени используют собственный интерфейс с системой, в большинстве случаев отличный от Win32 API. Среда разработки может быть обычной для используемой ОС РВ средой и может взаимодействовать со средой NT. Задачи реального времени будут выполняться, не получая преимуществ от механизма защиты памяти NT. Особо аккуратно следует продолжать выполнение частей реального времени, когда NT рухнет и сгенерирует голубой экран. След памяти — это комбинация следа NT (8 Мбайт в стандартной конфигурации) плюс минимальные требования для части ОС РВ.

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

• Сохранение (почти) всей среды 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.

4.4. Использование многопроцессорной архитектуры

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

• Нет модификаций каждой ОС;
• Можно применять в больших сложных системах;
• Для каждой подсистемы можно выбрать свою, наиболее подходящую ОС РВ;
• Можно использовать имеющиеся среды разработки.

Недостатки:

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

***

Чудес не бывает. Если вы хотите сохранить высокую совместимость с NT, то надо будет заплатить и более высокую цену. Если вы интересуетесь только частью интерфейса Win32 API, то можете работать с ОС РВ, имеющей этот интерфейс.

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

---

Необходимые требования к ОС для обеспечения предсказуемости

Требование 1. ОС РВ должна быть многонитевой и допускать вытеснение (preemtible).

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

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

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

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

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

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

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

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

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

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

Евгений Хухлаев — сотрудник Института прикладной математики имени М.В. Келдыша РАН, (Москва).

Начать хочу с благодарности Антону, который открыл тему и сформулировал очень сложные вопросы ответы на некоторые из которых (на многие, как мне кажется) мне представляются очевидными, хотя и объемными в изложении в соответствии с этой своей сложностью. Собственно, я и хочу изложить эти ответы и продемонстрировать их очевидность, а также откуда берется и с чем связана указанная сложность, которая трансформируется в объем и как и почему она в него трансформируется.

Исходная статья лежит здесь

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

системы управления автоматической системой усиления на основе измерения мощности по периодическим прерываниям АЦП и выводом рассчитанного коэффициента в ЦАП на фоне постоянного статусного-управляющего обмена по последовательной шине,

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

Еще очень впечатляют и восхищают вот такие заявления:

«Вы путаете Embedded OS и RTOS, между ними нет строгого знака равенства. Отсюда и весь посыл статьи заведомо ошибочен.»

Хочется спросить, а вы на какие определения того и другого опираетесь, а вы уверены, что они придуманы не для того, чтобы их путать? Ведь если между ними нет строгого знака равенства, это значит между ними есть НЕ строгий знак равенства. А раз есть хоть какой-то знак равенства то почему же их не спутать? Получается заявление противоречит само себе: утверждает, что они очень похожи, но запрещает их путать. Заявление достойно какой то блондинки, а блондинки всегда у меня вызывают восхищение .

Про термины и их определения

Дело в том, что термины всегда вводятся с какой-то целью и самая естественная цель — это сократить объем документации в которой используется термин за счет того, что не надо повторять разные составляющие определения этого термина. Я думаю (наверно даже знаю) ОСРВ это что-то гораздо больше термина который предполагается использовать в таких целях. ОСРВ скорее тянет на название стандарта, описывающего такой тип Операционных Систем или … на термин из области маркетинга, цель которого просто обратить внимание – выделить позиционируемый под таким названием продукт, воспользоваться модным названием, полное значение которого надо неделю изучать по иностранным (поскольку отечественных не существует), а значит малодоступные стандартам. Поэтому строгого определения, скажем на пол страницы, для ОСРВ не существует, существуют стандарты, которые определяют такое понятие страниц на 10-50-100, я не проверял. Причем какой-нибудь медицинский стандарт по этому поводу может быть совершенно не согласованным с подобным авиационным стандартом.

Multimedia systems некоторые определяют как SOFT системы реального времени

Теперь давайте вернемся к провокационному вопросу в заголовке, Windows тоже RTOS? Конечно, одна из целей такого провокационного вопроса в заголовке привлечь внимание к статье (иначе зачем я ее пишу, если не надеюсь на интерес аудитории!)

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

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

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

По поводу предлагаемой к рассмотрению задачи: я с удивлением нашел у Антона в статье что в иностранной практике multimedia systems тоже рассматриваются как системы реального времени:

Another kind of real-time system is a soft real-time system, in which missing an occasional deadline, while not desirable, is acceptable and does not cause any permanent damage. Digital audio or multimedia systems fall in this category. Digital telephones are also soft real-time systems.

Я одно время очень плотно и успешно работал над этой всем известной задачей, которая, как, надеюсь будет видно из моего опыта, очень близка (как минимум) к задачам реального времени, это задача декодирования-проигрывания видео. Не все осознают, что цель этой задачи именно управление «железом»: устройствами отображения и воспроизведения звука именно в реальном времени, хотя, по-моему, это очевидно. Задача задает четкие требования по времени отображения очередного кадра и синхронизации отображения кадров со звуком. Если у вас кино записано с частотой, скажем, 25 (а бывает и 50, и 60) кадров в секунду, это значит у вас есть 1000/25 = 40 мс чтобы:

1. прочитать данные из файла (из источника данных)

2. разделить потоки видео и аудио

3. декодировать аудио фрейм

4. декодировать достаточно аудио данных

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

6. записать аудио данные в аппаратный циркулярный буфер звукового устройства (вовремя записать!)

7. в нужный момент, в соответствии с периодом (40 мс) дать команду видеокарте на переключение отображаемого фрейма

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

Относительно «вовремя записать», можно отметить, что аудио буферу не нужна команда что бы он проиграл очередную порцию сэмплов, но надо следить что бы у него не кончились данные или чтобы он не перешел в зону не переписанных данных (контролировать overflow или underflow). Не менее сложной задачей при реализации видео плеера является синхронизация звука и видео, потому что уже при задержке в пол секунды между ними смотреть кино становится неприятно (как минимум).

Еще для справки, очень среднего разрешения кино имеет фрейм размером 640 х 480 = 307 200 х 4 байта для передачи цвета = 1,228,800 байт – больше Мега байта данных надо пересылать в видео буфер каждые 40 мс, это уже не какая то мгновенная операция копирования, потом надо еще учитывать задержку аппаратуры, копируем, все таки, в аппаратный буфер.

У нас для задачи четко определен интервал времени, который должен быть выдержан для того, чтобы работа программы реализующей задачу была успешной, но с какой точностью мы должны выдерживать этот интервал? Какие отклонения от среднего допустимы, 5 мс, 10 мс, … можно позволить? Как это выбрать?

Как не странно это звучит у человеческого глаза тоже есть технические характеристики , мы не замечаем пульсации света примерно меньше 1/7 секунды, собственно отсюда и взялись 25 кадров в секунду – это с запасом для особо чувствительных. Получается, что можно в принципе даже один фрейм иногда пропустить если получится сделать это так, что программа при этом не упадет (для тех, кто понимает сложность реализации такой фичи).

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

Что же в этом сложного? Дело в том, что чтобы измерять время нужно время! И это не тавтология — это рефлексия, это замкнутый круг, в который тем не менее надо в начале корректно войти, корректно отсчитывать периоды, и в конце корректно выйти.

А где же катастрофа? или критерий критичности задачи

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

Но представьте, что вы занимаетесь техническим обеспечением трансляции важного выступления уважаемого руководителя в очередном 37 году. Задача станет не только задачей реального времени во всех смыслах этого словосочетания, задача станет задачей фатальной ответственности. Таким образом, можно видеть, что критичность задачи — параметр достаточно условный, и я бы даже сказал очень субъективный – то что для одного будет безделицей для другого легко может стать трагедией и катастрофой. Вряд ли можно ориентироваться на такой субъективный параметр в технических вопросах, задачу в любом случае надо решать надежно и эффективно. А если есть задача ее решение должно обеспечить стабильность и эффективность использования системных и аппаратных ресурсов.

Про Операционную Систему саму по себе

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

Как говорил Мюллер Штирлицу: «Никому нельзя верить, Мне можно!», но в данном случае мне можно верить, потому что я начинаю с определения.

Так вот можно попробовать сформулировать что такое Операционная Система (ОС) вообще. Мне нравится мое определение (не только по понятной причине, но и по тому к каким очевидным выводам оно ведет):

ОС — это программа, которая определяет доступные пользователю операции из расширяемого списка, для примера:

1. открыть-запустить на исполнение файл

2. все операции с файлами: копировать, удалить, …

3. Создать/удалить поток (thread)

4. Создать/удалить семафор

5. Стандартные операции ввода в стандартной консоли или все возможные операции с окнами

6. Поддержка операций copy/past между исполняемыми модулями (поверьте имеет очень интересную реализацию на системном уровне)

7. Удалите все что вам не нравится

8. Добавьте свое

с сущностями, которые определены в этой ОС для операций пользователем или исполняемым модулем из расширяемого списка, для примера:

1. Файлы данных

2. Файлы исполняемые (я, и многие я думаю, знают примеры ОС которые не работают с файлами)

3. Файлы библиотек (статических, динамических)

4. Устройства и их программы обслуживания-доступа, известные как драйвера,

5. Семафоры, потоки, мутексы, …

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

7. Консоли, Окна, любые объекты для визуального взаимодействия с ОС

8. Удалите все что вам не нравится

9. Добавьте свое

Мы видим, что при определении ОС нам тоже не обойтись без рефлексии. ОС определяется тем, что сама эта ОС может делать, и тем, что она определяет как управляемые сущности в рамках себя самой!

Если мы вводим какое-то уточненное название как Real Time ОС понятно, что мы должны уточнить это общее определение для просто ОС.

Что же мы можем уточнить в общем определении ОС что бы было понятно, что имеется в виду именно РТОС? По-моему, совершенно очевидно: мы должны внести в расширяемый список операций тот набор обязательных операций, которые должна поддерживать РТОС!!!

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

Как же добиться характеристик реального времени (или универсальность математики)

Такой интересный заголовок (без добавки) есть у Антона в статье.

Я думаю, Антон хотел сказать что-то вроде:

Так чем же все-таки определяется принадлежность ОС к разряду Операционных Систем реального времени?

И предлагается ответ, с которым трудно не согласиться: «Это время и предсказуемость.»

Единственное, мне кажется тут следует дополнить или где-то даже поправить это заключение.

Принадлежность к ОСРВ определяется все-таки не просто временем (временем чего?), а предоставленной системой возможностью контролировать время:

1. измерять время

2. задавать периоды

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

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

Предсказуемость не является характеристикой подлежащей численной оценке, надо найти характеристику, которая дает численную характеристику предсказуемости и такая характеристика, конечно, есть – математика универсальна.

Покажем, что предсказуемость считается через разрешение по времени (кстати тут опять рефлексия или как это здесь называется? Разрешение по времени — это производная величина от времени которая имеет размерность времени).

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

Событие произойдет через время Treal такое что Т <= Treal < (T+1 МИЛЛИ секунда), то есть в этом случае мы исходим из того что разрешение по времени которое обеспечивает нам система это 1 мили секунда!

Но ведь вполне может оказаться что Т <= Treal < (T+1 МИКРО секунда), так как система обеспечивает нам разрешение по времени в МИКРО секундах. Никто же не может запретить нам использовать миллисекунды если можно использовать ДАЖЕ микросекунды!

Я думаю, всем понятно, что предсказуемость момента события в течение 1 мкс в 1000 раз выше, чем предсказуемость момента события в течение миллисекунды.

Из этого примера видно, что предсказуемость — это не абсолютная величина – это величина отношения разрешений по времени! Предсказуемость момента события в первой системе в 1000 раз меньше, чем предсказуемость момента события во второй системе и зависит это от разного разрешения по времени которое обеспечивают эти две системы, точнее от отношения этих разрешений.

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

P.S.

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

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

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

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

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

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

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

Т.о.
даже поверхностный анализ Windows NT
показывает, что эта система не годится
для построения систем жесткого РВ
(система непредсказуема — время выполнения
системных вызовов и время реакции на
прерывания сильно зависит от загрузки
системы; система велика; нет механизмов
защиты от зависаний и пр.). Поэтому даже
в системах мягкого РВ Windows
NT
м.б. использована только при выполнении
ряда рекомендаций и ограничений.

21. Операционные системы реального времени и Windows [2]

Разработчики
расширений пошли двумя
путями:

– использовали
ядра классических операционных систем
реального времени в качестве дополнения
к ядру Windows NT. Таковы решения фирм «LP
Eleknroniks» и «Radisys». В первом случае
параллельно с Windows NT (на одном компьютере!)
работает операционная система VxWorks,
во-втором случае — InTime. Кроме того,
предоставляется набор функций для связи
приложений реального времени и приложений
Windows NT. Технология использования двух
систем на одном компьютере понятна —
работу с объектом выполняет приложение
реального времени, передавая затем
результаты приложениям Windows NT для
обработки, передачи в сеть, архивирования
и пр.

– вариант
расширений реального времени фирмы
VenturCom выглядит иначе: здесь сделана
попытка «интегрировать» реальное
время в Windows NT путем исследования причин
задержек и зависаний и устранения этих
причин с помощью подсистемы реального
времени. Предложения VenturCom характерны
еще и тем, что они предоставляют совершенно
экзотическую для NT возможность, а именно
— возможность конфигурирования Windows NT
и создания встроенных конфигураций
(без дисков, клавиатуры и монитора).

Область
применения расширений реального времени
— большие системы реального времени,
где требуется визуализация, работа с
базами данных, доступ в интернет и пр.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #

Встраиваемые системы

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

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

Физически, к встраиваемым системам относится масса устройств — от MP3-плееров до больших стационарных систем, таких как «умные» светофоры или интеллектуальные датчики на электростанциях.

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

• NetBSD,
• Windows CE,
• Windows XP Embedded,
• Symbian OS.

Реальное время

Вычисления в реальном времени (Real-Time Computing — RTC) — это вычисления, удовлетворяющие ограничениям реального времени (Real-Time Constraint); то есть интервал времени между событием и реакцией системы не превышает некоторого порогового значения. Соответственно системы, не относящиеся к системам реального времени (non-real-time system), не имеют ограничений на время отклика, даже если к ним предъявляются требования высокой производительности и быстрого отклика.

Программное обеспечение реального времени обычно разрабатывается на основе операционных систем реального времени (real-time operating systems) с использованием синхронных языков программирования (synchronous programming languages).

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

Жесткое и «мягкое» реальное время

Систему считают системой реального времени, если корректность выполнения операции зависит не только от логической корректности операции, но и от времени ее выполнения. Считается, что в случае систем жесткого реального времени ( hard или immediate real-time system) завершение операции по истечении заданного интервала времени (наступления «дедлайна») является бесполезным и в конечном счете может привести к критическому сбою всей системы. Системы мягкого реального времени ( soft real-time system) допускают задержки и предпринимают различные меры для реакции в заданный интервал, например, снижая качество возвращаемого ответа (пропуск кадров в видео).

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

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

Как происходит распределение системного времени в случае систем, предназначенных для решения более одной задачи? Как правило, время распределяется на основании приоритетов задач. Кроме того, существуют алгоритмы, отдающие предпочтение задачам, которым осталось меньше всего времени на выполнение (Earliest Deadline First). Такие алгоритмы подходят для систем, загруженных менее чем на 100%.

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

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

Windows Embedded

Семейство встраиваемых Windows включают следующие операционные системы: Windows CE, Windows XP Embedded и Windows Embedded for Point of Service.

Windows XP Embedded

Windows XP Embedded (Xpe) — компонентная версия Microsoft Windows XP Professional. В основе ХРе — те же двоичные коды, что и у XP Pro, но XPe ориентирован на разработчиков для OEM, ISV и IHV, которым требуется полноценная поддержка Win32 API, но не нужны некоторые компоненты Professional. XPe запускает существующие Windows-приложения и драйверы устройств на устройствах с 32MB памяти Compact Flash, 32MB RAM и микропроцессором P-200.

XPe не имеет отношения к Wndows CE. Они ориентированы на различные устройства и оба имеют свои преимущества и недостатки. Например, XPe не сможет работать на некоторых достаточно малых объемах памяти, на которых работает CE. Однако CE не поддерживает полноценное Win32 API, которое поддерживает XPe (в CE есть аналог Win32 API). CE не сможет исполнять сотни уже разработанных драйверов и тысячи существующих приложений.

К устройствам, на которые ориентирована XPe, можно отнести торговые и игровые автоматы, кассовые аппараты, промышленных роботов, тонких клиентов, компьютерные приставки, сетевые устройства хранения данных, таймеры, устройства навигации и т. д. Различные версии XPe могут быть развернуты на самых разных устройствах, за исключением полноценного ПК. XPe поддерживает все оборудование, поддерживаемое XP Pro. Его нельзя установить на обычный ПК ввиду лицензионных ограничений.

Windows CE

Windows CE (WinCE) — версия операционной системы Microsoft Wndows для сильно ограниченных по сравнению с обычными ПК компьютеров и встраиваемых систем. Ядро Wndows значительно отличается от ядра Wndows для обычного ПК и не является урезанной версией. Ядро Win CE поддерживает архитектуры, совместимые с Intel x86, MIPS, ARM и Hitachi SuperH.

Windows CE специально оптимизирована для устройств, имеющих мало памяти — ядро Wndows CE требует для исполнения менее мегабайта памяти. Устройства часто конфигурируются без привлечения внешнего дискового устройства. Более того, можно настроить конфигурацию устройства так, чтобы получить изолированную от внешних пользователей систему (конечный пользователь не сможет расширять систему). Это можно сделать, записав образ ОС в ROM.

Windows CE соответствует определению системы реального времени (в отличие от XPe) с детерминированной задержкой обработки прерываний. Win CE поддерживает 256 уровней приоритета и поддерживает наследование приоритетов. Основной единицей исполнения является поток. Это позволяет упростить решение вопросов наследования и улучшить время исполнения.

На основе Win CE было разработано множество платформ (наиболее распространенные на сегодняшний день — Mobile 2003, Mobile 5.0, Smartphone 2003) и множество промышленных устройств и встраиваемых систем.

Значительная часть Windows CE поставляется с открытыми исходными кодами. В частности, Platform Builder (интегрированная среда создания образа ОС на основе Wndows CE) предлагает несколько компонент в форме исходных кодов.

Итоги

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

Появление таких операционных систем, как Wndows CE и Wndows XP Embedded, существенно упрощает разработку встраиваемых систем. А возможность использования .NET Compact Framework упрощает создание прикладных программ и различных сервисов для устройств.

2006 г. Операционные системы реального времени И.Б. Бурдонов, А.С. Косачев, В.Н. Пономаренко Препринт Института системного программирования РАН Назад Оглавление Вперёд 2.5. Расширения реального времени для Windows NT Windows NT проектировалась и, в основном, используется как универсальная ОС. Однако на рынке систем реального времени четко прослеживается тенденция использовать Windows NT и ее расширения в специализированных системах. На это существует несколько причин: Windows NT проектировалась согласно современным технологиям построения ОС, программный интерфейс приложений (API) для Win32 стал де-факто стандартом для программистов, графический пользовательский интерфейс (GUI) стал настолько популярным, что другие ОС стараются обеспечить похожий интерфейс, доступно большое количество драйверов устройств, доступны многие мощные интегрированные среды разработки. Сама по себе Windows NT не подходит для применения в системах реального времени, поскольку в ней слишком мало приоритетных уровней, отсутствует механизм наследования приоритетов. Для минимизации времени обработки прерываний (ISR) в Windows NT введена концепция отложенного вызова процедуры (DPC – deferred procedure call), приоритет которой выше, чем приоритет пользовательских и системных потоков, в то время как все DPC имеют одинаковый приоритет. Это приводит к тому, что все DPC ставятся в очередь FIFO, и DPC с высокоуровневым прерыванием сможет выполниться только после того, как все другие DPC, стоящие в очереди перед ней, будут выполнены. Такие ситуации ведут к непредсказуемым временам отклика, что несовместимо с требованиями к ОСРВ. Управление памятью в Windows NT основано на механизме виртуальной памяти. Это тянет за собой защиту памяти, трансляцию адресов и подкачку, которая неприемлема в ОСРВ. 2.5.1. RTX для Windows NT Расширение реального времени RTX (Real Time Extension) для ОС Windows NT (разработано корпорацией VenturСom) позволяет создавать приложения для высокоскоростного управления с детерминированным временем реакции на внешние события [RTX]. RTX глубоко интегрировано в ядро Windows NT и для обеспечения необходимых функций использует сервис Windows NT и API WIN32. Ядро реального времени (nucleus) интегрировано в ядро NT (kernel). Каждый процесс RTX выполняется как драйвер устройства ядра NT, при этом процессы не защищены друг от друга. Такая реализация приводит к быстрому переключению контекста, но небезопасна с точки зрения конфиденциальности. Расширения реального времени добавляют к Windows NT специфическую для реального времени функциональность. Обеспечивается возможность создавать процессы реального времени, управляемые собственным планировщиком. Этот планировщик работает уже по правилам реального времени и использует алгоритм вытеснения по приоритетам. Кроме того, процессы реального времени имеют преимущество перед стандартными процессами Win32, вытесняя их. Процессы реального времени имеют совсем иную, по сравнению со стандартными процессами Windows NT, степень надежности и специфическую функциональность. Процессы реального времени и стандартные процессы Win32 имеют средства взаимодействия друг с другом. Процессы реального времени имеют свой собственный программный интерфейс RTAPI, реализующий развитый набор средств, характерный для программных интерфейсов (API) ОСРВ. Приложение может использовать как стандартные функции Win32, так и специфические функции API реального времени (RTAPI), что позволяет выделять критические участки кода приложений Windows NT и контролировать время и надежность их выполнения. Имеется возможность контроля над работоспособностью и временами реакции системы. Зависания стандартных приложений Windows NT или крах системы не приводят к зависанию приложений реального времени. Предоставляется возможность работы с быстрыми часами и таймерами высокого разрешения. Обеспечивается возможность прямого доступа к памяти и физическим устройствам. RTX включает в себя следующие компоненты: уровень абстракции аппаратуры HAL (Hardware Abstraction Layer) реального времени (Real-Time HAL). HAL является программным компонентом самого низкого уровня при взаимодействии драйверов ядра с аппаратурой. В частности, именно на уровне HAL происходит первоначальная обработка прерываний от таймера, подсистему реального времени RTSS (Real-Time Subsystem), программный интерфейс расширений реального времени RTAPI (Real-Time Application Programming Interface). HAL реального времени подменяет стандартный HAL Windows NT. Подсистема реального времени RTSS обеспечивает выполнение большинства функций и управление ресурсами расширений реального времени. С точки зрения реализации, RTSS выглядит как драйвер Windows NT и выполняется в режиме ядра. Это позволяет достаточно простым способом устроить взаимодействие между процессами реального времени и процессами Windows NT. RTSS обеспечивает выполнение функций RTAPI и содержит планировщик потоков реального времени со 128-ю фиксированными приоритетами. RTSS содержит также менеджер объектов, предоставляющий унифицированные механизмы использования системных ресурсов. По сравнению с набором объектов Windows NT, добавлены такие объекты, как таймеры и обработчики прерываний. Работа с прерываниями Real-Time HAL. Перехватывая аппаратные прерывания, Real-Time HAL различает прерывания, относящиеся к обработчикам реального времени и обработчикам Windows NT. Прерывания, которые должны обрабатываться драйверами Windows NT, отправляются по стандартной цепочке. При этом Real-Time HAL следит за тем, чтобы прерывания не маскировались драйверами Windows NT более чем на 5 мкс, исключая возможность пропуска критического события. Быстрые часы и таймерные службы. Для измерения временных интервалов или для генерации прерываний Real-Time HAL позволяет работать с тиккером, разрешение которого 1 мкс. Системный таймер синхронизирован с тиккером, и может работать с периодом 100 мкс или быстрее, обеспечивая работу как стандартных таймерных сервисов, так и дополнительных, входящих в состав подсистемы реального времени. Поддержка подсистемы реального времени (RTSS). Кроме перечисленных выше функций (прерывания и таймеры), Real-Time HAL содержит поддержку функционирования всей подсистемы реального времени. Так, на основе прерываний от таймера строится диспетчер процессов реального времени. Real-Time HAL отвечает также за выполнение функций ввода-вывода подсистемы реального времени и пр. Программный интерфейс реального времени RTAPI является расширением Win32 и содержит, прежде всего, набор функций, необходимых для управления устройствами. RTAPI реализован в двух видах – как подмножество вызовов подсистемы реального времени (RTSS) и как динамическая библиотека (DLL), которая может вызываться из Win32-приложений. RTAPI содержит следующие группы функций: управление процессами и потоками – предоставляет Win32-совместимый интерфейс для управления, создания, изменения приоритетов, профилирования и завершения потоков реального времени, управление объектами RTSS – предоставляет возможности унифицированного управления объектами RTSS (создание, закрытие, доступ). Объектами RTSS являются: таймеры, обработчики преры-ваний и исключительных ситуаций (startup, shutdown, blue screen), потоки, процессы, семафоры, мьютексы (mutex), разделяемая память, почтовые ящики, консольный и файловый ввод-вывод, регистры. Взаимодействие между процессами. В RTAPI используются семафоры, мьютексы и разделяемая память для взаимодействия как потоков реального времени между собой, так и для их взаимодействия с процессами WIN32. Управление памятью позволяет фиксировать приложения в памяти, запрещая их выгрузку в файл подкачки. Доступ к физической памяти: приложение пользователя получает возможность доступа к данным по физическим адресам памяти. Управление прерываниями позволяет назначать и запрещать обработчики прерываний, разрешать и запрещать прерывания. Управление часами и таймерами разрешает создавать, удалять, отменять, инициализировать таймеры, назначать обработчики прерываний. Управление вводом-выводом RTAPI предоставляет два способа управления устройствами ввода-вывода. Во-первых, приложения пользователя получают возможность непосредственного доступа к адресам портов ввода-вывода, что позволяет программировать работу устройств напрямую. Кроме того, внешнее устройство может управляться специальными (легко разрабатываемыми) драйверами, для работы с которыми RTAPI предоставляет специальный интерфейс. 2.5.2. INtime Система INtime является расширением реального времени Windows, которое было разработано корпорацией Radisys Corporation, а в настоящее время поддерживается корпорацией TenAsys [INTIME]. INtime комбинирует возможности ОСРВ жесткого реального времени со стандартными ОС Windows, включая Windows XP, Windows XP Embedded, Windows 2000, Windows NT и Windows NT Embedded, не требуя дополнительной аппаратуры. INtime специально разработана под архитектуру процессора x86. Приложения реального времени и не реального времени выполняются на разных виртуальных машинах на единственном компьютере (см. рис. 4). INtime, в отличие от RTX, слабо связана с NT. Архитектура INtime основана на механизме аппаратного обслуживания задач (hardware tasking), которое обеспечивается процессором Intel. Получается, что два ядра выполняются на одной аппаратуре. Поскольку они разделяют одну аппаратуру, потребовались некоторые модификации NT HAL. Такой подход позволяет защитить и отделить среду выполнения и область памяти от Windows. Внутри INtime каждый процесс приложения имеет свое собственное адресное пространство. Кроме того, ядро и приложения выполняются на разных приоритетных уровнях, что позволяет защитить их друг от друга. INtime показывает предсказуемое поведение, однако ее сложная архитектура не позволяет достичь системе хорошей производительности. Из-за сегментационных ограничений INtime подходит не для всех систем реального времени. Рис. 4. Структура INtime. 2.5.3. Microsoft Windows Embedded Операционные системы Microsoft Windows Embedded для встраиваемых систем имеют две разновидности в соответствии с версиями ОС Windows – NT и XP [MSEmb]. Версии систем Embedded корпорации Microsoft состоят из многочисленных конфигурируемых частей, которые позволяют легко манипулировать набором установленного программного обеспечения. Windows NT Embedded использует технические ресурсы Windows NT и позволяет разрабатывать приложения, которые могут быть легко интегрированы в существующую информационную инфраструктуру. Набор средств разработки – Target Designer и Component Designer – позволяет OEM (original equipment manufacturer) производителям конфигурировать и создавать операционную систему для конкретной аппаратной платформы. Windows NT Embedded обладает специфическими компонентами для создания встраиваемых систем, которые позволяют работать в системах без видеоадаптера, осуществлять загрузку и работу накопителей в режиме «только чтение», выполнять удаленное администрирование и предоставляют дополнительные средства обработки ошибок и восстановления. Windows NT Embedded дает возможность создавать устройства, с которыми работать так же просто, как и со стандартными ПК на основе Windows, и управлять этими новыми устройствами на основе существующих профессиональных продуктов, таких как Microsoft Systems Management Сервер, HP OpenView, IBM Tivoli, CA Unicenter TNG, и др. Рис. 5. Процесс разработки встраиваемого ПО на основе Windows NT Embedded. Разработчик встраиваемых систем применяет для конфигурирования ОС Target Designer, используя готовый двоичный код Windows NT, дополнительные компоненты для встраивания и дополнительные приложения. В случае необходимости, для создания новых компонентов, не входящих в состав продукта (например, драйверов устройств, приложений и пр.), может использоваться Component Designer. Вновь созданные новые компоненты могут быть импортированы в Target Designer и включены в состав целевой ОС. После конфигурирования ОС с помощью Target Designer происходит проверка взаимосвязей компонентов и строится образ системы, готовый к загрузке и исполнению на целевой системе. Windows XP Embedded насчитывает до 10000 отдельных компонентов, а в Windows NT Embedded их было чуть больше 300. Основной отличительной чертой Windows XP Embedded является четкое разграничение компонентов системы, что позволяет разработчикам встраиваемого набора функций при создании образа системы включать только необходимые файлы и максимально сократить размер результирующей системы. Этими компонентами служат отдельные части системы Windows XP Professional. Компоненты Windows XP Embedded представлены сервисами, приложениями, библиотеками и драйверами – разработчику нужно сконфигурировать необходимый набор функций и собрать из компонентов необходимую конфигурацию в образ среды исполнения (runtime image). Все опции конфигурации собраны воедино в базу данных компонентов. Разработчик имеет к ней доступ и может ее редактировать с помощью специального инструмента – Component Database Manager. Для каждого компонента в процессе создания определяется ряд параметров: платформа, на которой будет выполняться данный компонент (определяет порядок компиляции и сборки); описание и схема подключения компонента; список ассоциированных ресурсов, таких как файлы и ключи реестра; зависимости компонента от других компонентов (например, от DirectX или NET runtime); указатель на хранилище файлов (чаще всего это просто локальный каталог, но может быть и сетевым ресурсом); принадлежность к группе для упрощения обращения сразу к нескольким компонентам как к целому. Сама база данных управляется СУБД MS SQL Server и может быть расположена как локально, на компьютере разработчика, так и на сервере. Назад Оглавление Вперёд