Лекция 1. системы реального времени. виды ос рв. требования к ос рв

Планирование задач

Работа планировщика

Большинство ОСРВ выполняет планирование задач, руководствуясь следующей схемой. Каждой задаче в приложении ставится в соответствие некоторый приоритет. Чем больше приоритет, тем выше должна быть реактивность задачи. Высокая реактивность достигается путём реализации подхода приоритетного вытесняющего планирования (preemptive priority scheduling), суть которого заключается в том, что планировщику разрешается останавливать выполнение любой задачи в произвольный момент времени, если установлено, что другая задача должна быть запущена незамедлительно.

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

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

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

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

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

Выполнение задачи

В обычных ОСРВ задача может находиться в трёх возможных состояниях:

  • задача выполняется;
  • задача готова к выполнению;
  • задача заблокирована.

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

Основная функция администратора ОСРВ заключается в составлении такого планировщика задач.

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

Алгоритмы планирования

В настоящее время для решения задачи эффективного планирования в ОСРВ наиболее интенсивно развиваются два подхода:

  • статические алгоритмы планирования (RMS, Rate Monotonic Scheduling) — используют приоритетное вытесняющее планирование, приоритет присваивается каждой задаче до того, как она начала выполняться, преимущество отдаётся задачам с самыми короткими периодами выполнения;
  • динамические алгоритмы планирования (EDF, Earliest Deadline First Scheduling) — приоритет задачам присваивается динамически, причём предпочтение отдаётся задачам с наиболее ранним предельным временем начала (завершения) выполнения.

При больших загрузках системы EDF более эффективен, нежели RMS.

Планировщик ЦП в реальном времени

системы мягкого реального временисистемы жесткого реального времени

  • Задержка прерывания относится к периоду времени от поступления прерывания в CPU до запуска процедуры обработки. Когда происходит событие, ОС должна сначала завершить выполняемую инструкцию и определить тип возникшего прерывания. Затем она должна сохранить состояние текущего процесса до обработки прерывания с помощью специальной процедуры, interrupt service routine (ISR).
    Рис. 1 Задержка прерывания.
  • Время, необходимое диспетчеру планирования для остановки одного процесса и запуска другого, называется задержкой диспетчеризации. Предоставление задач реального времени с немедленным доступом к процессору требует, чтобы ОС реального времени минимизировали также и эту задержку. Наиболее эффективным методом поддержания низкой задержки отправки является предоставление ядер с приоритетным прерыванием.
    Рис. 2 Задержка диспетчеризации.

Поддержка языка Visual Basic .NET

Для создания интерфейсов, обеспечивающих взаимодействие с RTX-приложениями, многие разработчики хотели бы использовать Visual Basic вместо традиционных языков C и C++, поскольку это существенно экономит время. С появлением в RTX 6.1 поддержки языка Visual Basic .NET они получили такую возможность.
Какие операционные системы поддерживаются в RTX 6.1? Перечень доступных для RTX операционных систем был пересмотрен с учётом того, какие ОС корпорации Microsoft официально поддерживаются в настоящий момент. Версия RTX 6.1 утратила совместимость с платформой Windows NT. Теперь продукт RTX поддерживает следующие ОС:

  • Windows 2000 (до пакета обновления
  • Windows XP Professional (до пакета обновления SP2 включительно); 
  • Windows XP Embedded (до пакета обновления SP2 включительно); 
  • Windows 2000 Server.

Тестирование производительности RTX

Какова же реальная производительность RTX, особенно в сравнении с другими системами? В литературе приводится множество результатов тестирования RTX , однако остановимся более подробно на сравнительных тестах (см. Таблицу) для Windows XP, Windows CE .NET и RTX 5.5 . В качестве тестового использовался компьютер с процессором 800 MHz Pentium III с поддержкой ACPI.

Примеры использования RTX

Основные области применения RTX – телекоммуникации, обработка изображений и приём/передача информации в реальном времени, промышленная автоматизация, системы оборонного назначения, медицина. В качестве примера рассмотрим один из проектов, приведенных на последней конференции по RTX во Франции (2005 год).

Компания Woodhead использует RTX (рис. 5) в системах АСУТП как на нижнем уровне работы c платами семейства Direct-Link по протоколу CANopen (http://www.can-cia.org/products/pg2004/html/index-246.htm), так и на уровне диспетчерского интерфейса.

Рис. 5. Пример использования RTX компанией Woodhead

Заключение

Как показывает опыт, ни одно из решений в области систем реального времени не позволяет охватить весь спектр приложений. Свою долю рынка имеет каждая из ОСРВ LynxOS, QNX, VxWorks, Integrity. В первую очередь, это системы специального назначения. Однако расширения реального времени для офисных операционных систем (такие, как RTX), также имеют ряд достоинства и способны найти своё применение. Поэтому наряду с ОСРВ нельзя забывать и о них, особенно с учётом показателя «цена решения/функциональные возможности».

Литература

  1. Bob Kilbridge, Windows NT and Windows 2000 for real-time applications. 
  2. Interview: Venturcom s Real-time, benchmarking, and tools for XP Embedded, http://www.windowsfordevices.com/articles/AT8823921976.html, 2003.
  3. Interview: Adding deterministic, real-time control to XP Embedded using Intime, http://www.windowsfordevices.com/articles/AT5426953592.html, 2003.
  4. Chris Tacke, Lawrence Ricci, Real-time determinism in Windows CE , http://www.windowsfordevices.com/articles/AT6761039286.html, Dec. 2002.
  5. Nat Frampton, John Tsao, Jerry Yen , Hard Real-time Extensions of Windows NT Evaluation Report, 1998.
  6. Павел Кирюхин. RTX – расширение реального времени для Windows NT, http://www.citforum.ru/operating_systems/rtx/index.shtml, 1998.
  7. Martin Timmerman, Jean-Christophe Monfret, Windows NT as Real-Time OS? // Real-Time Magazine. 1997. Q2.
  8. Philip Melanson, Siamak Tafazoli. A Selection Methodology for the RTOS Market. Canadian Space Agency. 2003.
  9. Mike Cherepov, Mike Hirst, Chris Jones, Myron Zimmerman, Hard Real-Time with Venturcom RTX on Microsoft Windows XP/ XPe, http://www.windowsfordevices.com/articles/AT3618198049.html, 2002.
  10. Greg Bergsma, Realtime Extensions to Windows NT, http://www.swd.de/documents/papers/nt_en.html, 1998.
  11. Жданов А. NT – реально ли реальное время? // Открытые системы. 1998. N1.

Об авторе: Сергей Золотарев сотрудник отдела программных продуктов компании RTSoft

Статья была опубликована в журнале МКА 5/2005 и на сайте rtsoft.ru

Помещена в музей с разрешения редакции
6 января 2019

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

Существуют различные типы основных функций ОСРВ:

  1. Планировщик на основе приоритетов
  2. Процедура прерывания системного тактирования
  3. Детерминированное поведение
  4. Синхронизация и обмен сообщениями
  5. Служба ОСРВ

Планировщик на основе приоритетов

В планировщике на основе приоритетов большая часть ОСРВ имеет от 32 до 256 возможных приоритетов для отдельных задач или процессов. Этот планировщик запустит процесс с наивысшим приоритетом. Если задача выполняется на ЦП, то выполняется следующая задача с наивысшим приоритетом, которая продолжает процессы. В системе процесс с наивысшим приоритетом будет иметь процессор.

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

Готов к запуску (Ready to Run). Говорят, что готовность к запуску наступает тогда, когда у процесса есть все ресурсы для запуска, но он не должен находиться в рабочем состоянии.

Запущен (Running). Если задача выполняется, то говорят, что она запущена.

Заблокирован (Blocked). В этом состоянии, если у процесса недостаточно ресурсов для запуска, он переводится в заблокированное состояние.

Процедура прерывания системного тактирования

Для выполнения чувствительной ко времени операции ОСРВ предоставит определенное системное тактирование. Если, например, такт 1 мс, то вы должны выполнить задачу за 50 мс. Обычно за этим следует API, который говорит: «Через 50 мс разбудите меня». Следовательно, задача будет в спящем режиме, пока ОСРВ не проснется. Тем не менее, пробуждение не гарантирует, что оно будет работать точно в это время, это зависит от приоритета, и если в данный момент работает более высокий приоритет, то данная задача будет отложена.

Детерминированное поведение

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

Службы ОСРВ

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

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

  • Службы синхронизации
  • Службы обработки прерываний
  • Службы управления устройствами
  • Службы управления памятью
  • Службы ввода-вывода

Поддержка подсистемы реального времени (RTSS)

Подсистема реального времени RTSS обеспечивает исполнение большинства функций и управление ресурсами расширений реального времени. С точки зрения реализации RTSS выглядит как драйвер Windows и выполняется в режиме ядра. Это позволяет достаточно простым способом устроить взаимодействие между процессами реального времени и процессами Windows. Подсистема RTSS обеспечивает исполнение функций RTAPI и содержит планировщик нитей реального времени со 128-ю фиксированными приоритетами. В ней также содержится менеджер объектов, предоставляющий унифицированные механизмы использования системных ресурсов. По сравнению с набором объектов Windows добавлены таймеры и обработчики прерываний. Интерфейс RTAPI является расширением Win32 и содержит прежде всего набор функций, необходимых для управления устройствами. Он реализован в двух видах: как подмножество подсистемы реального времени (RTSS) и как динамическая библиотека (DLL), которая может вызываться из Win32-приложений. Интерфейс RTAPI содержит следующие группы функций:

  • управление процессами и нитями: Win32-совместимый интерфейс для управления, создания, изменения приоритетов, профилирования и завершения нитей реального времени;
  • управление объектами RTSS: возможности унифицированного управления объектами RTSS (создание, закрытие, доступ). Объектами RTSS являются таймеры, обработчики прерываний и исключительных ситуаций (startup, shutdown, blue screen), нити, процессы, семафоры, мьютексы, разделяемая память, почтовые ящики, консольный и файловый ввод/вывод, регистры;
  • взаимодействие между процессами: использование семафоров, мьютексов (mutex) и разделяемой памяти как для взаимодействия нитей реального времени между собой, так и процессов реального времени с процессами WIN32;
  • управление памятью: позволяет фиксировать приложения в памяти, запрещая их выгрузку в файл подкачки;
  • доступ к физической памяти: приложение пользователя получает возможность доступа к данным по физическим адресам памяти;
  • управление прерываниями: содержит функции, позволяющие назначать и запрещать обработчики прерываний, разрешать и запрещать прерывания;
  • часы и таймеры: содержит функции управления часами и таймерами (создание, удаление, отмена, инициализация таймеров, назначение обработчиков прерываний);
  • управление вводом/выводом: имеется два способа управления устройствами ввода/вывода. Во-первых, приложения пользователя получают возможность непосредственного доступа к адресам портов ввода/вывода, что позволяет программировать работу устройств напрямую. Кроме того, внешнее устройство может управляться специальными (легко разрабатываемыми) драйверами, для работы с которыми RTAPI предоставляет специальный интерфейс.

Расширение RTX поддерживает как однопроцессорные, так и многопроцессорные конфигурации для Windows NT, 2000 и XP. Исполнительная версия RTX, которая поддерживает работу многопроцессорных систем, обеспечивает все возможности однопроцессорной версии плюс возможности многопроцессорных систем, совместимых с архитектурой Intel MPS, что позволяет значительно повысить производительность приложений. Мультипроцессорная версия RTX реализует модель «выделенного процессора», в которой RTSS выполняется только на одном процессоре, в то время как на других процессорах выполняются стандартные приложения Windows.

Защита памяти с помощью модулей ОСРВ Azure ThreadX

Дополнительный продукт, называемый модулями ОСРВ Azure ThreadX, позволяет объединить один или несколько потоков приложения в модуль, который можно динамически загружать и запускать (или выполнять на месте) на целевом оборудовании.

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

Модули также используют диапазон адресов, отдельный от ОСРВ Azure ThreadX. Это позволяет ОСРВ Azure ThreadX применять защиту памяти (посредством MPU или MMU) для модуля, которая не позволяет непреднамеренному обращению извне модуля повредить какой-либо другой программный компонент.

Настройка приложения Nucleus SE

nuse_config.hnuse_config.c

Настройка nuse_config.h

#definenuse_config.hСчётчики объектовNUSE_SEMAPHORE_NUMBERNUSE_SIGNAL_SUPPORTRUEАктиваторы функций API NUSE_PIPE_JAMTRUEВыбор планировщика и его настройкиNUSE_SCHEDULER_TYPENUSE_RUN_TO_COMPLETION_SCHEDULERNUSE_TIME_SLICE_SCHEDULERNUSE_ROUND_ROBIN_SCHEDULERNUSE_PRIORITY_SCHEDULERNUSE_TIME_SLICE_TICKSNUSE_SCHEDULE_COUNT_SUPPORTTRUEFALSENUSE_SUSPEND_ENABLENUSE_SUSPEND_ENABLETRUEДругие параметрыTRUEFALSENUSE_API_PARAMETER_CHECKINGNUSE_INITIAL_TASK_STATE_SUPPORTNUSE_READYNUSE_PURE_SUSPENDNUSE_READYNUSE_SYSTEM_TIME_SUPPORTNUSE_INCLUDE_EVERYTHING

Настройка nuse_config.c

nuse_config.hnuse_config.cnuse_config.cДанные задачNUSE_Task_Start_Address[]NUSE_Idle_Task()ADDRNUSE_Task_Stack_Base[]NUSE_Task_Stack_Size[]NUSE_INITIAL_TASK_STATE_SUPPORTNUSE_Task_Initial_State[]NUSE_READY или NUSE_PURE_SUSPENDДанные пулов разделовU8NUSE_Partition_Pool_Data_Address[]NUSE_Partition_Pool_Partition_Number[]NUSE_Partition_Message_Size[]Данные очередейADDRNUSE_Queue_Data[]NUSE_Queue_Size[]Данные каналов передачи данныхU8NUSE_Pipe_Data[]NUSE_Pipe_Size[]NUSE_Pipe_Message_Size[]Данные семафоровNUSE_Semaphore_Initial_Value[]Данные таймеров приложенияNUSE_Timer_Initial_Time[]NUSE_Timer_Reschedule_Time[]NUSE_TIMER_EXPIRATION_ROUTINE_SUPPORTTRUENUSE_Timer_Expiration_Routine_Address[]NUSE_Timer_Expiration_Routine_Parameter[]

Возможно, вам также будет интересно

«Театрально-техническая корпорация» (ТТК, Санкт-Петербург) является одним из лидеров на российском рынке оборудования для сценических комплексов, а также в сфере услуг по их проектированию, монтажу и обслуживанию. Компания оснастила более 3000 объектов культуры в стране и за рубежом. И уже более 10 лет ТТК использует решения компании Schneider Electric для управления сценическим оборудованием.

Компания «ФИОРД» (официальный дистрибьютор CompuLab в России) объявляет о начале приема заявок на поставку fit-PC3.  fit-PC3 – ультракомпактный ПК на базе многоядерных «процессоров ускоренной обработки» APU AMD серии G продолжает традиции других устройств в линейке fit-PC «самых маленьких ПК в мире».

В начале апреля в немецком Штутгарте компания Emerson проводила свою Users Exchange Conference для региона EMEA.
О масштабе и репутации компании свидетельствует уже то, что это, по сути, «монобрендовое» мероприятие собрало около 1200 участников. Программа конференции включала промышленный форум, то есть доклады сотрудников подразделений Emerson из разных стран и заказчиков, делившихся своим оп…

Объем памяти ThreadX

ОСРВ Azure ThreadX требуется очень мало ресурсов — всего 2 КБ для области хранения команд и 1 КБ ОЗУ. В основном это обусловлено одноуровневой архитектурой picokernel и автоматическим масштабированием. Автоматическое масштабирование означает, что во время компоновки в окончательный образ добавляются только службы (и поддерживающая инфраструктура), используемые приложением.

Ниже приведены типичные размеры для ОСРВ Azure ThreadX.

Служба ОСРВ Azure ThreadX Типичный размер в байтах
Основные службы (обязательные) 2 000
Службы очередей 900
Службы флагов событий 900
Службы семафоров 450
Службы мьютексов 1200
Службы блоков памяти 550
Службы управления байтами памяти 900

Больше, чем ПЛК

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

SEA воспользовалась ОСРВ RTX (компании Citrix г. Волтхем (Waltham), Массачусетс), установленной на промышленном компьютере Simatic Microbox 420. ОСРВ предоставляет гораздо больше возможностей, чем это кажется на первый взгляд. „Они смотрят на компьютер и считают, что это ПЛК…, не понимая, что ОСРВ — это гораздо больше, чем ПЛК»,-говорит Кацзор.

Одна из ключевых возможностей — это возможность и средства коммуникации. Поль Чен (Paul Chen), менеджер по линии продуктов VxWorks в компании-производителе ОСРВ Wind River Systems (г.Аламеда, Калифорния) отмечает, что взаимодействие с внешним миром — это необходимое требование для современной операционной системы реального времени. Система должна поддерживать такие общепринятые интерфейсы как USB, Ethernet и беспроводную связь. Пользователям также требуется внедрение таких стандартов как Internet нового поколения (IPv6), различные варианты беспроводного протокола 802.х MIPv4 и MIPv6 для мобильных приложений и средства обеспечения безопасности: IPsec и HTTPS.

Требования производителям ОСРВ диктуют пользователи. „Если операционная система реального времени не будет обладать нужной функциональностью, пользователям придется дописывать нужные компоненты самим»,-говорит Чен.

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

То же самое можно сказать и о вопросах безопасности и защиты информации. Они возникают в аэрокосмических, промышленных и медицинских приложениях, которые регулируются стандартами, начинающимися 3-х буквенными аббревиатурами: FAA DO-178B, IEC 61508 и FDA 510(k).

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

В настоящее время существует тенденция объединения всех уровней в одном приборе, то есть защита доступа к самой важной информации осуществляется с помощью программно-аппаратных средств

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

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

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

Планирование в Nucleus RTOS

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

Планировщик может поддерживать неограниченное количество задач (ограниченное лишь доступными ресурсами) и работать с управлением по приоритетам. Задаче может быть назначен приоритет от 0 до 255, где 0 — наивысший приоритет, а 255 — самый низкий. Задача обладает динамическим приоритетом, то есть он может быть изменен во время выполнения либо самой задачей, либо другой. Нескольким задачам может быть присвоен одинаковый уровень приоритета. В крайнем случае всем задачам может быть назначен один и тот же приоритет, что дает возможность реализовать политику планирования по принципу Round Robin и Time-Slice.
Если существует несколько задач с одним и тем же приоритетом, они будут запланированы по алгоритму Round Robin, в том порядке, в котором были подготовлены. Задаче нужно приостановиться или передать управление, чтобы запустилась следующая задача. Задачам также могут быть назначены временные интервалы, которые обеспечивают более контролируемое разделение доступного времени процессора.

Планирование задач на 100% детерминировано, чего и следовало ожидать от подобного ядра. Задачи также могут быть динамически созданы и уничтожены, что, благодаря планировщику, происходит незаметно для пользователя.

Поддержка технологии Physical Address Extensions

Технология расширения физических адресов (Physical Address Extensions – PAE) корпорации Intel позволяет адресовать до 64 Гбайт физической памяти. До недавнего времени большинство операционных систем для процессоров с архитектурой IA-32 были способны поддерживать лишь 32-разрядную адресацию, что ограничивало объём доступной им памяти величиной в 4 Гбайт. Ситуация изменилась с выходом пакета обновления Windows XP Pro SP2, где по умолчанию имеется поддержка технологии PAE. Новая версия RTX поддерживает PAE для всех реализаций слоя HAL. Продукт RTX 6.1 позволяет использовать в целевой системе до 64 Гбайт оперативной памяти.