Автор работы: Пользователь скрыл имя, 19 Января 2015 в 18:43, реферат
Операционные системы реального времени (ОСРВ) предназначены для обеспечения интерфейса к ресурсам критических по времени систем реального времени. Основной задачей в таких системах является своевременность (timeliness) выполнения обработки данных.
В качестве основного требования к ОСРВ выдвигается требование обеспечения предсказуемости или детерминированности поведения системы в наихудших внешних условиях, что резко отличается от требований к производительности и быстродействию универсальных ОС. Хорошая ОСРВ имеет предсказуемое поведение при всех сценариях системной загрузки (одновременные прерывания и выполнение потоков).
1. Введение: Особенности операционных систем реального времени
1.1. Процессы, потоки, задачи
1.2. Планирование, приоритеты
1.3. Память
1.4. Прерывания
1.5. Часы и таймеры
1.6. Стандарты ОСРВ
1.6.1. POSIX
1.6.2. DO-178B
1.6.3. ARINC-653
1.6.4. OSEK
1.6.5. Стандарты безопасности
1.7. Настраиваемость операционных систем
2. Краткие характеристики наиболее распространенных ОСРВ
2.1. VxWorks
2.2. QNX Neutrino RTOS
2.3. RTEMS
2.4. ChorusOS
2.5. Расширения реального времени для Windows NT
2.5.1. RTX для Windows NT
2.5.2. INtime
2.5.3. Microsoft Windows Embedded
2.6. TinyOS
2.7. OSEK/VDX
2.8. OSE RTOS
2.9. Contiki
2.10. pSOS
2.11. INTEGRITY
2.12. LynxOS
2.13. Microware OS-9
2.14. GRACE-OS
2.15. C EXECUTIVE
2.16. CMX-RTX
2.16.1. CMX-TINY+
2.17. Inferno
3. ОС, разработанные специально для портативных устройств
3.1. ITRON
3.2. Windows CE
3.3. JavaOS
3.4. Jbed
3.5. Nucleus RTOS
3.6. EMERALDS
3.7. CORTEX
3.8. DeltaOS
3.9. Palm OS
3.10. Symbian OS (EPOC)
4. Настраиваемость операционных систем
4.1. Адаптация, осуществляемая человеком
4.1.1. Статическая адаптация, инициированная проектировщиком
4.1.2. Динамическая адаптация, инициированная администратором
4.2. Адаптация, инициированная приложением
4.2.1. Адаптация с уровня приложения
4.2.2. Адаптация на уровне ядра
4.3. Автоматическая адаптация
5. Сводные таблицы характеристик свойств ОСРВ
С целью улучшения переносимости приложений в них могут использоваться константы и макросы, описывающие конфигурацию ядра,. Метод, который используется для определения констант и макросов конфигурации ядра, является реализацинннно-зависимым. Обычно они определяются в заголовочных файлах ядра или могут быть сгенерированы конфигуратором. Как альтернатива, они могут быть определены в заголовочных файлах приложения и затем использованы для конфигурации ядра.
Системы семейства Microsoft Windows CE [WinCE] являются открытыми, масштабируемыми ОС, позволяющими компоновать ОС для широкого диапазона современных небольших устройств, которые соединяют в себе компьютерные, телефонные и сетевые возможности. Устройство, на которое может быть установлена Windows CE, обычно проектируется для специализированного использования, часто работает автономно и требует маленькой ОС, которая имеет детерминированные реакции на прерывания.
Последней версией из этого семейства является система Microsoft Windows CE 5.0, в которой объединены возможности систем реального времени и последние технологии Windows. В отличие от других ОСРВ Windows CE проектировалась так, чтобы она была совместимой с универсальными ОС.
ОСРВ Windows CE является модульной с небольшим ядром и необязательными модулями, которые выполняются как независимые процессы. Планирование в Windows CE осуществляется на основе приоритетов. Поддерживается защита ядра и процессов друг от друга. Кроме того, возможен режим работы, когда отсутствует защита между процессами и ядром. Следует отметить, что прерывания обрабатываются как потоки и имеют уровни приоритетов потоков. Windows CE поддерживает также нити (fiber), являющиеся потоками, которыми ядро не управляет. Каждая нить выполняется в контексте потока, который ее создал; их можно использовать для создания планировщика внутри потока. Такие нити используются в экзотических или унаследованных приложениях, но они непригодны в системах реального времени.
Windows CE имеет ограничение на физическую память – 512MB. Microsoft ввел это ограничение для того, чтобы Windows CE могла выполняться на большом диапазоне встраиваемых процессоров без проблем совместимости, поскольку некоторые из этих процессоров способны управлять физической памятью в 512MB. Однако физическая память может быть отображена в адресные регионы, размер которых превышает 512MB.
RAM в устройстве Windows CE разделяется на две области – хранилище объектов и программная память. Хранилище объектов напоминает постоянный виртуальный диск RAM. Данные в таком хранилище запоминаются во время приостановки или операции частичной переустановки (soft reset). Когда операция возобновляется, система находит ранее созданное хранилище объектов и использует его. Программная память состоит из оставшейся RAM, она работает как RAM в персональном компьютере – запоминает стеки и области для динамически выделяемой памяти (heaps) выполняющихся приложений.
Во время старта Windows CE создает единое виртуальное адресное пространство в 4GB, которое затем разделяется на две секции – ядро и пользовательское пространство, как и в универсальной ОС Windows. Далее пользовательское пространство делится на 64 слота по 32MB, из которых 32 резервируются для процессов (отсюда ограничение на число процессов в системе). Все процессы разделяют виртуальное адресное пространство, но не имеют доступа друг к другу. В виртуальном адресном пространстве в 32MB находится все, что нужно процессу – программа, данные, область динамической памяти (heap). Если процесс имеет соответствующие права доступа, он может получить память сверх ограничения в 32MB, обратившись к специальному процессу (VirtualAlloc) или используя файлы, отображаемые на память (memory mapped files).
Windows CE реализует страничное управление виртуальной памятью. Размер страницы зависит от платформы, но, по возможности, используется размер в 4KB. Есть возможность запретить страничную организацию, что важно для систем реального времени. В этом режиме модуль перед выполнением целиком загружается в память. Тогда страничная подкачка (paging) не повлияет на выполнение приложения.
В обычной конфигурации для защиты ядра и процессов друг от друга используется MMU. Есть возможность сконфигурировать Windows CE без защиты памяти между процессами и ядром, что позволяет достичь большей производительности системы.
Рис.14. Процесс разработки ОС Windows CE.
Механизмы синхронизации в Windows CE можно разделить на две категории:
В отличие от других ОСРВ Windows CE поддерживает обобщенные функции ожидания для различных типов объектов (мьютексов, семафоров, событий, процессов и потоков). Преимущество таких функций состоит в том, что можно ожидать многие объекты сразу, пока один из них не подаст сигнал. Критические секции можно использовать только внутри одного процесса. Вычислительные семафоры и мьютексы могут быть использованы как внутри одного процесса, так и между процессами.
В Windows CE используется наследование приоритетов, чтобы избежать проблемы инверсии приоритетов.
Windows CE позволяет построить, отладить и внедрить настроенную ОС из предлагаемого набора компонентов с помощью инструмента Platform Builder. Процесс разработки ОС Windows CE показан на рис. 14.
На рис. 15 приведена архитектура ОС Windows CE.
Рис. 15. Архитектура ОС Windows CE.
Введение адаптационного уровня производителя в архитектуру Windows CE позволило повысить ее эффективность.
Хотя Windows CE имеет модульную структуру, которая позволяет создавать минимальные конфигурации для небольших систем, она все-таки остается сложной и требует относительно большого пространства на диске, поэтому она не является хорошим выбором для глубоко встраиваемых систем.
JavaOS – это семейство небольших по размеру, эффективных операционных систем, оптимизированных для поддержки Java-среды и предназначенных для выполнения на тонких клиентах – сетевых компьютерах [SM99]. JavaOS проектировалась для выполнения приложений, написанных на языке Java, и была создана корпорацией Sun Microsystems для того, чтобы виртуальная машина Java (JVM) непосредственно выполнялась на микропроцессорах, без участия резидентной операционной системы.
В отличие от реализаций Java над универсальными ОС, JavaOS обеспечивает не только экономию ресурсов (что важно в первую очередь для встраиваемых систем), но и снижение затрат на администрирование (что сулит существенную экономию для корпоративных систем).
Семейство JavaOS включает три разновидности ОС:
Для обеспечения конфигурирования JavaOS имеет базу данных, состоящую из именованных Java-объектов. Эта база данных помогает поддерживать динамическую реконфигурацию.
Характерной чертой JavaOS является стремление к максимальной независимости от платформы. Такая независимость способствует мобильности самой JavaOS и построенных на ее основе программных систем, что очень важно в условиях большого разнообразия аппаратных модификаций и частой смены моделей. Для достижения независимости от платформы внутри JavaOS выделены технологические интерфейсы – с платформой (JavaOS Platform Interface, JPI) и периферийными устройствами (JavaOS Device Interface, JDI). Все, что выше этих интерфейсов, может быть написано на Java и сделано мобильным.
JavaOS построена по принципу многослойной архитектуры, в которой каждый слой может обновляться независимо от всех остальных. Архитектура JavaOS состоит из микроядра и диспетчера памяти, драйверов устройств, виртуальной машины Java, систем JavaOS Graphics и JavaOS Windowing, сетевых классов и средств поддержки всех интерфейсов прикладного программирования (API) Java. Приложения, написанные для JavaOS, совместимы с браузерами и операционными системами, соответствующими стандартам Java.
В многослойной архитектуре JavaOS код разделяется на платформенную и платформенно-независимую части. Платформенный код, который компилируется в машинный код, состоит из ядра и виртуальной машины Java. Платформенно-независимая часть JavaOS (написанная на Java) состоит из систем JavaOS Window и Graphics, драйверов устройств JavaOS и сетевых классов JavaOS.
Микроядро JavaOS поддерживает начальную загрузку, управление прерываниями, многопоточность, управление перехватами и распределением динамической памяти. Микроядро также поддерживает ряд сервисов сеанса работы, которые включают виртуальную машину Java, сборщик мусора и сервисный загрузчик.
Рис. 16. Многослойная архитектура JavaOS.
Драйверы устройств JavaOS написаны на языке Java и являются переносимыми и расширяемыми. Сетевые классы JavaOS, также написанные на Java, реализуют стандартные промышленные сетевые протоколы, такие как TCP/IP и др.
Уменьшение объемов платформенно-зависимых частей JavaOS упрощает администрирование корпоративных конфигураций, делая их более однородными. Это важное средство снижения общей стоимости владения клиентскими частями информационных систем.
Стоит отметить, что микроядро JavaOS для эффективной привязки к аппаратному обеспечению или к другой операционной системе создается на языке C и соответствующем языке ассемблера.
Для JavaOS характерна распределенная работа ее компонентов, безопасность данных, а также контроль использования ресурсов, как сервера, так и клиента.
JavaOS перенесена на системы с микропроцессорами SPARC, x86 и ARM. Для полной сетевой реализации с поддержкой рабочей среды Java (Java Runtime Environment) нужно 2.4 MB памяти. JavaOS с браузером HotJava требует минимального объема памяти в 4 MB.
Система Jbed фирмы Oberon Microsystems, является ОСРВ с ядром, ориентированным на Java-технологию [Jbed98], и может рассматриваться как Java-платформа для встроенных систем и систем реального времени. Другими кандидатами Java-платформ являются такие системы, как EmbeddedJava и JavaCard. В основном они различаются средствами поддержки потоков, сбора мусора, поддержкой чисел с плавающей запятой и т.п. В Jbed ядро в действительности и есть Java-машина, которая также называется runtime-системой. В Jbed runtime-система, как минимально возможная система, обеспечивает планирование потоков, распределение памяти и сбор мусора. Такая конфигурация требует 64KB оперативной памяти. Другие возможные конфигурации могут включать минимальную систему с TCP/IP и веб-сервером (что требует 128KB) или минимальную систему с сетевым загрузчиком и компилятором для трансляции Java-кода в машинный код целевого компьютера (что требует 256KB). В терминах настраиваемости операционных систем это означает, что компоненты ядра обладают крупным уровнем детализации, и к тому же в Jbed отсутствует возможность динамической конфигурации на уровне ядра.
Микроядро Jbed обладает специфическими особенностями, необходимыми для встроенных систем и систем реального времени, такими как малый объем требуемой памяти, поддержка потоков реального времени и управление дедлайнами.
Над ядром выстраиваются такие компоненты, как драйверы периферийных устройств, драйверы устройств связи, сетевые загрузчики, библиотеки. Эти компоненты называются встроенными приложениями, и подгружаются они по требованию. Таким образом, на этом уровне Jbed обеспечивает динамическую настраиваемость. Кроме того, уровень приложений поддерживает клиент-серверную модель. На этом уровне такие приложения, как управление процессами, удаленная диагностика и система сигнализации, называются клиентами. Серверные программы управляют клиентскими компонентами (встроенными приложениями), которые могут осуществлять отладку, удаленное управление или работать как веб-серверы. Серверы позволяют клиентам удаленно диагностировать встроенные приложения, замещать компоненты и удаленно управлять встроенными системами с некоторого персонального компьютера. Однако эти возможности не доступны на уровне ядра операционной системы. Получается, что на уровне ядра конфигурирование заключается просто в выборе одной из упомянутых выше конфигураций.
Операционная система Nucleus, разработанная корпорацией Accelerated Technology, предназначена для встраиваемых приложений [NUCLEUS]. Nucleus является кросс-системой, т.е. программный продукт создается на одной программно-аппаратной платформе, а выполняется на другой. ОСРВ Nucleus поставляется вместе с открытым кодом.
Ядро ОСРВ Nucleus, Nucleus PLUS, обеспечивает многозадачную обработку, является переносимым и масштабируемым. Ядро реализовано как библиотека функций на языке C. Nucleus PLUS предоставляет такие возможности, как управление взаимодействием задач (почтовые ящики, очереди, конвейеры, семафоры, события, сигналы), а также управление памятью, таймерами, прерываниями. Планирование задач осуществляется на основе приоритетов, а также по алгоритму FIFO. При выполнении системного вызова выполнение задачи может приостанавливаться на неопределенное время, на заданный интервал, или не приостанавливаться. Все объекты в системе могут создаваться и удаляться динамически.
EMERALDS (Extensible Microkernel for embedded, ReAL-time, Distributed Systems) [ZS01] – это микроядро реального времени, написанное на языке C++, которое предназначено для малых и средних по размеру встраиваемых систем. Система EMERALDS является научной разработкой Мичиганского университета (University of Michigan).
EMERALDS обеспечивает обработку многопоточных процессов. Процесс в EMERALDS является пассивной сущностью, характеризующейся защищенным адресным пространством, в котором выполняются потоки. Каждый поток имеет приоритет, присвоенный ему пользователем; на основе приоритетов ядро осуществляет планирование потоков. В ядре также обеспечивается системный вызов, позволяющий изменить приоритет потока во время выполнения. Для обеспечения эффективной защиты памяти ядро отображается в адресное пространство каждого процесса. При таком отображении переключение из приложения в ядро вызывает прерывание (TRAP), которое переключает центральный процессор из приложения в режим ядра, и совершается переход на соответствующий адрес внутри того же адресного пространства.
Ядро обеспечивает такие сервисы, как семафоры, таймеры, управление памятью и пр. В качестве механизма взаимодействия процессов EMERALDS использует обмен сообщениями через почтовые ящики как для внутрипроцессного, так и для межпроцессного взаимодействия. Проблема инверсии приоритетов решается с помощью введения наследования приоритетов.
CORTEX – это многозадачная ОСРВ для встраиваемых приложений, разработанная корпорацией ARTESYS (Australian Real Time Embedded Systems). Исходный код системы свободно распространяется для образовательных и некоммерческих целей.
Управление задачами включает временную поддержку, реентерабельность, вытеснение, основано на управлении событиями, является детерминированным и поддерживает приоритеты. Доступны три разных политики планирования. Поддерживается 62 уровня приоритетов для задач. Приоритетное прерывание обслуживания может осуществляться непосредственно через сервисы управления вытеснением или косвенно с помощью взаимодействия между задачами и примитивов синхронизации. Поддерживается механизм наследования приоритетов.