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

Автор работы: Пользователь скрыл имя, 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. Сводные таблицы характеристик свойств ОСРВ

Прикрепленные файлы: 1 файл

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

— 1.25 Мб (Скачать документ)

OSE RTOS предлагает три варианта ядра, построенные по одному принципу. OSE Epsilon – для глубоко встраиваемой и SoC (system-on-chip) разработки. OSEck – компактное ядро для DSP. OSE Link Handler – для многочисленных смешанных CPU/DSP проектов. Все они поддерживают очень маленькое количество системных вызовов – от шести до восьми.

Архитектура OSE RTOS основана на многослойной модели (рис. 8).

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

OSE RTOS оперирует разными типами и категориями процессов.

Типы процессов:

  • Процессы прерываний возникают в ответ на аппаратные или программные прерывания, выполняются до конца, имеют самый высокий приоритет и такой же контекст, как и все другие процессы,
  • таймерные процессы прерывания аналогичны процессам прерываний, за исключением того, что они предусматриваются планировщиком периодически в соответствии с указанным периодом времени,
  • приоритетные процессы являются самыми распространенными процессами в OSE RTOS и выполняются до тех пор, пока не будут вытеснены процессом прерывания или процессом с более высоким приоритетом,
  • фоновые процессы выполняются строго в режиме циклического обслуживания с квантованием времени на приоритетном уровне, который находится ниже всех приоритетных процессов.

Рис.8. Многослойная архитектура OSE RTOS.

Под категориями процессов в OSE RTOS понимается разделение процессов на динамические и статические. Статические процессы создаются ядром, когда система стартует, и существуют на всем протяжении существования системы. Динамические процессы создаются и уничтожаются во время выполнения.

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

2.9. Contiki

Операционная система Contiki [DGV04] разработана в Швеции (Swedish Institute of Computer Science) для систем с ограниченной памятью. Система Contiki позволяет динамически загружать и отгружать приложения и сервисы. С целью минимизации размеров операционной системы было спроектировано ядро Contiki, которое основано на модели управления событиями [HSW00].

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

Многопоточный режим с приоритетами в системе Contiki реализован с помощью библиотеки приложений, которые выполняются над ядром, управляемым событиями. Приложения, обеспечивающие многопоточную обработку, компонуются с выполняющимся приложением по мере необходимости, т.е. если оно явно требует многопоточной модели вычислений. Выполняющаяся система Contiki разделяется на две части – сердцевину (core) и загруженные программы. Сердцевина (core) состоит из собственно ядра (kernel), базовых сервисов и фрагментов библиотек поддержки, в том числе языковой поддержки времени выполнения. Разделяемая функциональность реализуется через сервисы как некоторая форма разделяемых библиотек. Эти сервисы можно обновлять или замещать динамически независимо друг от друга во время выполнения, что, по мнению разработчиков, ведет к гибкой структуре системы.

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

Системы, управляемые событиями, имеют свои проблемы. Модель программирования, управляемая состояниями, сложна для программистов. К тому же не все программы укладываются в конечно-автоматную модель.

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

Рис. 9. Сердцевина Contiki и загруженные программы.

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

Contiki написана на языке C и адаптирована для ряда микроконтроллерных архитектур, включая Texas Instruments MSP430 и Atmel AVR, а также для платформы ESB.

2.10. pSOS

ОСРВ pSOS была разработана корпорацией Integrated Systems. В настоящее время она принадлежит корпорации WindRiver [PSOS], которая ее купила, видимо для того, чтобы она не мешалась на рынке сбыта ОСРВ.

Имя pSOSsystem присвоено операционной системе, имя pSOS+ – ее ядру. pRISM+ – это интегрированная среда разработки для создания приложений.

pSOS+ – это маленькое ядро встраиваемых приложений, представляющее собой некий вариант клиент-серверной архитектуры. Однако оно не имеет протокола взаимодействия, основанного на сообщениях. Для взаимодействия модулей используется программная шина (software bus). Есть возможность выбрать и встроить модули в систему во время компиляции. Такими модулями могут быть файловая система (pHILE+), отладчик (pROBE+), сетевые протоколы (pNA+), библиотека удаленных вызовов процедур (pRPC+) и стандартная библиотека ANSI C (pREPC+). Эти компоненты показаны на  
рис. 10.

Рис. 10. Компоненты pSOSsystem.

Вызовы различных приложений осуществляются через программные прерывания.

pSOS+m является многопроцессорной версией ядра pSOS+. Она требует, чтобы один узел был главным, а остальные – подчиненными. К этому ядру добавлены системные вызовы, позволяющие оперировать через границы процессора.

В pSOS+ не используется понятие процесса, вместо этого она оперирует задачами, что соответствует понятию потоков, выполняющихся в одном процессе. Все системные объекты разделяются между всеми потоками. Так как все потоки разделяют один и тот же контекст, время переключения потоков становится очень малым.

pSOSsystem имеет несегментированную модель памяти. Защита памяти может быть обеспечена через библиотеку управления памятью. Код, данные и стеки можно защитить с помощью определения отображений защиты памяти для каждой задачи. При этом ответственность ложится на разработчика приложений, а это является непростой задачей. pSOSsystem предлагает две абстракции для управления памятью – регионы и разделы. Регионы – это куски памяти нефиксированного размера, в то время как разделы – куски фиксированного размера. Управление памятью с помощью разделов обеспечивает быстрое выделение памяти.

Управление прерываниями в pSOSsystem довольно примитивное. Кроме того, отсутствуют мьютексы и механизм наследования приоритетов, что может привести к инверсии приоритетов.

2.11. INTEGRITY

Продукт INTEGRITY (компания Green Hills Software) [INTEGRITY] – это ОСРВ с предсказуемым временем отклика, рассчитанная на применение в тех ситуациях, когда необходимы масштабируемость ОС, её компактность и возможность работы в режиме реального времени. Платформа INTEGRITY построена на базе микроядра velOSity [Velosity] и хорошо подходит для использования в недорогих устройствах с ограниченными аппаратными ресурсами (сюда относится большая часть потребительской электроники). Для своей операционной системы компания Green Hills предлагает интегрированную среду разработки MULTI, полностью автоматизирующую процесс создания ПО. Поддерживая многоязыковую разработку и отладку, графический интерфейс пакета MULTI дает пользователю быстрый и удобный доступ к оптимизирующим C/C++ компиляторам и функциям MISRA C. В этом инструментальном пакете содержится отладчик уровня входного языка, компоновщик, анализатор событий, профилировщик производительности, программа обнаружения ошибок периода исполнения и средство отладки, не нарушающее основного режима функционирования.

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

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

Рис. 11. Структура INTEGRITY.

ОСРВ INTEGRITY включает двухуровневый планировщик ARINC-653, основанный на сегментации (Partition Scheduler), который обеспечивает гарантированное временное окно центрального процессора для каждой выполняющейся задачи. Например, если выполняются две задачи, A и B, и каждой предоставлено по 50% времени, то порождение задачей B задач B1 и B2 не повлияет на выполнение задачи A, поскольку время центрального процессора, выделенное для задачи В (50%), разделится на 3 для задач В, B1 и B2, а для задачи A останутся ее прежние 50%. Таким образом, действия одной задачи никогда не смогут повлиять на выполнение других задач, что позволяет избегать воздействия злоумышленного кода, вирусов, проникновения хакера или просто ошибок в других адресных пространствах.

2.12. LynxOS

Операционная система LynxOS RTOS (LynuxWorks, Inc.) является операционной системой жесткого реального времени, которая предназначена для специализированной и телекоммуникационной аппаратуры [LynxOS]. Эта ОС является полностью детерминированной и обладает POSIX-, UNIX- и Linux-совместимостью. Областями применения ОС LynxOS являются также сложные системы безопасности.

Последняя выпущенная версия этого бренда ОС LynxOS-178 2.0 характеризуется производителем как коммерческая операционная система, обеспечивающая высокий уровень надежности и оперативности, необходимый для встраиваемых приложений с особыми требованиями к безопасности. В LynxOS-178 2.0 реализована поддержка интерфейса APEX (APlication/EXecutive – интерфейс приложения/управляющей программы) спецификации ARINC-653. Это означает, что данная операционная система отвечает самым строгим требованиям к безопасности и надежности электронных систем для военной и гражданской авиации. Система LynxOS-178 2.0 полностью соответствует положениям уровня А спецификации DO-178B.

ОСРВ LynxOS-178 2.0 соответствует требованиям стандартов POSIX и ARINC-653, а также DO-178B, что означает гарантию переносимости прикладного кода встраиваемых систем, многократного использования созданных программ, а также соответствие самым строгим нормативам операционных систем с повышенными требованиями к безопасности. Использование LynxOS-178 2.0 позволяет применять любые ранее сертифицированные программы и разработки.

2.13. Microware OS-9

Операционная система реального времени OS-9 корпорации Microware System является многозадачной, многопользовательской операционной системой для встраиваемых приложений, работающих в режиме реального времени [OS-9]. Эта система предназначена для работы в таких системах, как мобильные телекоммуникационные устройства, встраиваемые терминалы доступа в Интернет, интерактивные цифровые телевизионные приставки. OS-9 работает на таких процессорах, как Motorola 68K, ARM/StrongARM, Intel IXP1200 Network Processor, MIPS, PowerPC, Hitachi SuperH, x86 or Intel Pentium, Intel IXC1100 XScale.

Ядро OS-9 является масштабируемым, полностью вытесняемым, поддерживает функционирование до 65535 процессов, предоставляет 65535 уровней приоритета и обеспечивает работу до 255 пользователей. Ядро OS-9 содержит более 90 системных вызовов, которые дают возможность управлять динамическим режимом диспетчеризации, распределением памяти, межпроцессорной коммуникацией и т.д. – вплоть до управления встраиваемым в ядро ОС режимом экономичного потребления питания. Характеристики производительности ядра: 5,6 мкс – время задержки прерывания (Interrupt Latence Time), 14 мкс – время переключения контекста процесса (для процессора MC68040, 30MHz).

Система ввода-вывода ОС поддерживает следующие форматы устройств массовой памяти и основных интерфейсов периферийных устройств: Raw, MS-DOS, True FFS, CardSoft PCMCIA, USB, IrDA.

Среда OS-9 поддерживает несколько программных коммуникационных платформ – mwSoftStax (Microware), Harris & Jeffries, Trillium. Благодаря наличию стандартизованной коммуникационной среды в OS-9 доступны современные и наиболее перспективные коммуникационные протоколы: ISDN, ATM, X.25, MPEG-2, FR, SS7 и т.д.

Графические средства в OS-9 представлены разнообразными продуктами – от компактных минимизированных по ресурсам программных модулей поддержки графики Multimedia Applications User Interface (MAUI) фирмы Microware до полнофункциональных клиент-серверных графических систем G-Windows (GESPAC), XiBase9 GUI (XiSys), MGR (Reccoware).

Корпорация Microware одной из первых лицензировала Java для встраиваемых приложений и является лидером по предложению разнообразных средств и приложений в рамках OS-9 для различных классов устройств. В OS-9 пользователю предлагается Java VM, Java-Compiler/JIT, Java-ROMizer, Java Applets Lib, Embedded Java, Personal Java.

В различных областях применения для портирования OS-9 на аппаратную платформу производителя используются следующие программные пакеты:

  • OS-9 for Embedded Systems Kit,
  • OS-9 for Communications Systems,
  • OS-9 for Consumer Devices (Wireless Devices),
  • OS-9 for Interactive Digital TV,
  • OS-9 Java Starter Kit.

В качестве интегрированной кросс-среды разработки приложений для OS-9 корпорация Microware разработала среду Hawk, которая функционирует на платформе MS Windows NT. Hawk является открытой средой и предоставляет сторонним разработчикам инструментальных средств более сотни API, позволяющих включать в состав среды Hawk продукты известных фирм разработчиков инструментального ПО.

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