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

Расширения реального времени добавляют к 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 и может быть расположена как локально, на компьютере разработчика, так и на сервере.

2.6. TinyOS

Разработка операционной системы TinyOS [HSW00] связана с появлением новой концепции беспроводной связи – Motes. Motes (в переводе с английского – пылинки, соринки) – это реализация идеи "smart-dust" ("распыленной разумности"), предложенной оборонным агентством Darpa (Defense Advanced Research Projects Agency), в частности, для отслеживания передвижений противника.

Motes разработаны в Калифорнийским  университете в Беркли совместно  с Intel, и в настоящее время ведутся  испытания этих самоорганизующихся  сетей, построенных на основе открытых технологий Intel Mote и программного обеспечения TinyOS, TinyDB.

Умные сенсоры Motes, распределенные в пространстве, могут самостоятельно связываться друг с другом, образуя распределенную беспроводную информационную сеть. "Пылинка разума" состоит из 8-битового микроконтроллера семейства Amtel AVR, приемопередающего интегрального модуля TR1000 и двух микросхем средней степени интеграции – энергонезависимой памяти и дополнительного загрузочного микроконтроллера, позволяющего по радиоканалу обновлять ПО центрального процессора – AVR.

"Smart-dust" создавалась для динамических, изменяющихся  как в пространстве, так и во  времени сетей – для той  области, в которой абсолютно  неприменимы ни традиционные  алгоритмы управления, ни отработанные принципы маршрутизации, ни архитектурные решения, лежащие в основе традиционного системного ПО. Стремление конструкторов сделать ее как можно более компактной (в перспективе – 1 мм3) влечет за собой ряд существенных ограничений, в первую очередь энергетических. Ограниченные вычислительные ресурсы и динамический характер сети приводят к тому, что функциональность "пылинки" надо время от времени изменять, что может быть достигнуто только одним способом – передачей по радиоканалу нужного ПО. С другой стороны, энергетическая дороговизна передачи информации требует сверхкомпактного представления передаваемого кода, в противном случае "пылинки" просто не будут работать из-за быстрого истощения крохотных автономных источников питания.

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

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