Операционные системы реального времени
Особенности операционных систем реального времени: процессы, потоки, задачи, планирование и приоритеты. VxWorks, QNX Neutrino RTOS, RTEMS, TinyOS, LynxOS, Inferno, портативные ITRON, Palm OS, Symbian и другие: разноуровневая адаптация и сравнение.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | дипломная работа |
| Язык | русский |
| Дата добавления | 10.05.2012 |
| Размер файла | 1,6 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
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 продукты известных фирм разработчиков инструментального ПО.
Для нужд совместной программно-аппаратной разработки в Hawk встроены средства для работы с внутрисхемными эмуляторами серии visionICE фирмы EST. Есть средства отладки в режиме реального времени.
Для тестирования и верификации ПО разработано средство верификации программного обеспечения CodeTEST (Applied Microsystems), встраиваемое в Hawk. Это средство дает возможность осуществлять трассировку встраиваемого ПО и контролировать его характеристики, а также ход выполнения тестов и распределение памяти.
2.14 GRACE-OS
</a)Система GRACE-OS представляет собой планировщик CPU в режиме мягкого реального времени для мобильных устройств, выполняющих, главным образом, мультимедийные приложения [YN03]. Система GRACE-OS разработана в Иллинойском университете (University of Illinois, Department of Computer Science). При проектировании системы первоочередными целями ставились задачи поддержки качества сервиса и сбережения энергии. Для достижения поставленных целей GRACE-OS интегрирует динамическое масштабирование напряжения в диспетчеризацию на основе модели мягкого реального времени и определяет, как быстро, когда и как долго должно осуществляться выполнение приложений. Планировщик GRACE-OS реализован внутри ядра Linux, и апробирован на лэптопе HP Pavilion.
Планировщик GRACE-OS состоит из трех основных компонентов - профайлера, планировщика SRT (soft real-time) и адаптера скорости, как показано на рис. 12.
Рис. 12. Архитектура GRACE-OS
Усовершенствованный планировщик выполняет планирование в режиме мягкого реального времени и динамическое масштабирование напряжения.
Профайлер осуществляет мониторинг коэффициента загрузки цикла отдельных задач и автоматически получает распределение вероятности их запросов внутри цикла в зависимости от коэффициента загрузки. Планировщик SRT отвечает за выделение циклов задачам и их планирование, обеспечивая необходимую производительность. Планирование в режиме мягкого реального времени основано на статистических требованиях производительности и распределении запросов каждой задачи. Адаптер скорости динамически регулирует скорость CPU, обеспечивая экономию энергии. Он адаптирует скорость выполнения каждой задачи на основе распределения выделяемого задачам времени, что обеспечивается планировщиком SRT, и распределения запросов, что обеспечивается профайлером.
2.15 C EXECUTIVE
C EXECUTIVE (JMI Software Systems, INC.) [CEXEC] - это многозадачное ядро реального времени для встраиваемых систем, работающее на 8-, 16- и 32-битовых CISC процессорах, на широком диапазоне RISC процессоров и DSP (Digital Signal Processor). Это ядро обеспечивает быстрое переключение контекста, имеет маленький размер. Над ядром можно надстраивать DOS-совместимую файловую систему, TCP/IP и SNMP.
Ядро C EXECUTIVE обладает высокой степенью масштабируемости, можно даже сказать, что масштабируемость внутренне присуща такому ядру, поскольку набор системных вызовов компонуется из библиотеки во время создания системы, и выполняющийся экземпляр системы будет содержать только те системные вызовы, которые используются конкретным приложением. К тому же такое ядро можно конфигурировать с включением или без включения квантования времени, генератора тактовых импульсов, сигналов и т.п., позволяя, таким образом, осуществлять крайне высокую оптимизацию системной конфигурации для небольших целевых систем.
Ядра реального времени компании JMI применяются в сотнях встраиваемых приложений, включая лазерные принтеры, электронные кассовые аппараты, медицинскую аппаратуру, устройства коммуникации, военные и космические приложения и другие критические по времени системы.
2.16 CMX-RTX
Операционная система CMX-RTX [CMXRTX] является многозадачной операционной системой реального времени для микроконтроллеров, микропроцессоров, микрокомпьютеров и DSP (Digital Signal Processor). Эта система поддерживает вложенные прерывания, имеет быстрое время переключения контекстов, низкие времена задержек прерываний и крайне малые размеры. Планировщик задач и компонент управления прерываниями написаны на языке ассемблера для ускорения вычислительного процесса. CMX-RTX имеет компоненты управления задачами, событиями, временем, сообщениями, очередями, ресурсами, семафорами, фиксированными блоками памяти, автоматическим выключением питания, асинхронной последовательной передачей данных (UART - universal asynchronous receiver-transmitter), приоритетными прерываниями.
2.16.1 CMX-TINY+
CMX-TINY+ [CMXTINY] является многозадачной операционной системой реального времени для широкого ряда микропроцессоров и микрокомпьютеров, которая создана для разработки приложений, выполняющихся под ОСРВ и использующих только встраиваемую память процессора. Эта система обеспечивает незначительно меньшую функциональность, чем система CMX-RTX. Она создавалась для того, чтобы ее можно было поместить внутри небольшой бортовой памяти RAM (random access memory) в чипе, которая имеет размер 512 байтов и больше.
2.17 Inferno
Inferno (корпорация Lucent) - это компактная операционная система, созданная для построения распределенных и сетевых систем на широком диапазоне устройств и платформ [INFERNO]. Эта система обладает межплатформенной переносимостью и может выполняться как пользовательское приложение или как независимая операционная система. Поддерживается для большинства широко распространенных операционных систем и платформ. Каждая система Inferno предоставляет пользователю идентичную среду разработки независимо от основной операционной системы или архитектуры, разрешая работать в гомогенной среде с множеством различных платформ.
Inferno - это не только операционная система; она также является полноценной средой разработки, обеспечивая все средства, необходимые для создания, отладки и тестирования приложений. Приложения, создаваемые в среде Inferno, пишутся на языке Limbo, который является модульным параллельным языком программирования с C-подобным синтаксисом. Код на Limbo компилируется в архитектурно-независимый байтовый код, который затем может быть выполнен в режиме интерпретации (или код компилируется оперативно) для целевого процессора. Таким образом, Inferno-приложения выполняются идентично на всех Inferno-платформах.
Inferno предлагает полную прозрачность ресурсов и данных, применяя некую систему именного пространства. Ресурсы представляются как файлы, применяется один стандартный коммуникационный протокол. Благодаря этому такие ресурсы, как хранилища данных, сервисы и внешние устройства, могут разделяться между различными Inferno-системами. Интерфейс ресурса можно импортировать в локальную систему, и им могут пользоваться приложения, которые не знают, является ли данный ресурс локальным или удаленным.
Безопасность высокого уровня также является частью Inferno-системы. Благодаря тому, что для всей сети используется один стандартный коммуникационный протокол, безопасность обеспечивается на системном уровне. Inferno предлагает также поддержку аутентификации, основанной на шифровании.
3. ОС, разработанные специально для портативных устройств
3.1 ITRON
ITRON (Industrial The Real-time Operating system Nucleus) - это широко распространенная в Японии операционная система для встроенных систем, которая используется в роботах, аппаратах факсимильной связи, цифровых камерах, а также в хостах разнообразных устройств [ITRON]. По сути, ITRON является открытым стандартом ОСРВ для встроенных систем. После создания в Японии спецификации µITRON (micro-ITRON) и быстро возросшей ее популярности корпорация Accelerated Technology (разработчик серии ОСРВ Nucleus с открытым исходным кодом) разработала ядро реального времени Nucleus µiPLUS, которое соответствует стандартам интерфейса µITRON, что позволяет переносить ранее созданные приложения, соответствующие этому стандарту, на широкий ряд процессоров, выполняющих Nucleus µiPLUS.
Создание ОС ITRON было вызвано необходимостью введения каких-либо стандартов в море несовместимых между собой операционных систем для встроенных систем. ITRON предлагает спецификации для стандартного ядра реального времени, которое с незначительными настройками могло бы выполняться на различных устройствах. Согласно оценкам японской прессы, от трех до четырех миллиардов микропроцессоров работают под управлением ОС ITRON.
Несмотря на эту популярность, ОС ITRON имеет большой дефект. Широкие возможности по модификации ОС ITRON, данные разработчикам для того, чтобы они могли подогнать спецификации ядра под свои требования, основано на концепции “слабой стандартизации”. Слабая стандартизация приводит к большим трудностям в создании унифицированной среды разработки ОС ITRON.
При проектировании спецификаций ITRON учитывались следующие технические требования к спецификациям ОСРВ для встроенных систем:
· извлекать максимальную производительность из аппаратуры,
· способствовать улучшению эффективности программного обеспечения,
· обеспечивать масштабируемость некоторого набора систем.
Чтобы спецификации ITRON удовлетворяли этим требованиям, они проектировались в соответствии со следующими принципами:
· Увеличить адаптируемость к аппаратуре, избегая чрезмерной виртуализации аппаратуры. Адаптация к аппаратуре означает изменение спецификаций ОСРВ и внутренних реализационных методов, приводящее к возрастанию производительности всей системы в целом. Более точно, спецификации ITRON вводят явное разграничение между аспектами, которые следует стандартизовать через аппаратную архитектуру, и вопросами, которые должны быть решены оптимально на основе природы аппаратуры и ее производительности. Среди аспектов, которые стандартизуются, выделяются правила планирования задач; имена и функции системных вызовов; имена, порядок и значение параметров; имена и значения кодов ошибок. Во всех других вопросах стандартизация и виртуализация не проводится, т.к. это может привести к снижению производительности во время выполнения. Это относится к размеру параметра в битах и методам, стартующим обработку прерываний, - такие вопросы решаются отдельно для каждой реализации.
· Учитывать адаптируемость к приложениям. Адаптация к приложению означает изменение спецификаций ядра и внутренних реализационных методов, которые опираются на функции ядра и производительность, требуемую приложением, с целью повышения производительности всей системы в целом. В случае встроенной системы объектный код ОС генерируется отдельно для каждого приложения; таким образом, адаптация к приложению работает особенно хорошо (рис. 13). При проектировании спецификаций ITRON такая адаптация сопровождается обеспечением независимости функций ядра друг от друга, насколько это возможно, тем самым, разрешая каждому приложению выбрать только те функции, которые ему необходимы. На практике это выражается в том, что большинство µITRON-спецификационных ядер поставляются в библиотечном формате. Каждый системный вызов обеспечивается единственной функцией, что позволяет легко встраивать только необходимые функции.
· Обеспечить простоту обучения разработчика программного обеспечения. В спецификациях ITRON стандартизация применяется как способ облегчения приобретения разработчиками необходимых навыков. Согласованность в использовании терминологии, именования системных вызовов и удобная справочная система гарантируют быстрое усвоение основных положений и широкое применение их впоследствии. Возможен и другой способ обучения - на основе изучения текстовых материалов.
· Организация спецификаций в серии и разделение на уровни. Чтобы обеспечить адаптацию к широкому многообразию аппаратуры, спецификации организуются в серии и подразделяются на уровни. Например, спецификация µITRON (версия 2.0) была создана, главным образом, для использования в системах с 8- или 16-битовых MCU, в то время как спецификация ITRON2 предназначена для 32-битовых процессоров. Каждая спецификация далее разбивается на уровни, основанные на степени востребованности каждой функции. При реализации ядра соответствующий уровень выбирается на основе предназначения приложений и требуемых для них функций. Последняя реализованная спецификация µITRON3.0 подразделяет системные вызовы на три уровня, что дает возможность одной этой спецификацией покрывать диапазон от маломасштабных до крупных процессоров. Спецификации для распределенных и многопроцессорных систем также могут быть стандартизованы с помощью серий ITRON-спецификаций.
· Обеспечивать широкий набор функциональных возможностей. Примитивы ядра не ограничиваются малым количеством функций, напротив, они покрывают широкий диапазон разнообразных возможностей. Выбирая примитивы, которые хорошо подходят для данного типа приложения и аппаратуры, системные разработчики смогут быстро и легко создавать программы, обеспечивающие высокую производительность времени выполнения.
Из доступных версий спецификаций ITRON самой последней является спецификация µITRON4.0. Рассмотрим ее более подробно.
Под термином “задача” в системе ITRON понимается единица параллельной обработки. Переключение выполнения с одной задачи на другую называется диспетчеризацией. Процесс выбора следующей задачи для выполнения называется планированием.
Рис. 13. Адаптация в спецификации µITRON.
Для описания состояния задач система ITRON оперирует следующими понятиями:
· Выполняющаяся (running),
· Готовая к выполнению (ready),
· Блокированная (bloked)
· Ждущая (waiting) - ожидается выполнение каких-либо условий,
· Приостановленная (suspended) - остановлена другой задачей или самой собой,
· Ждущая-приостановленная (waiting-suspended) - ожидаются условия и приостановлена,
· Спящая (dormant) - еще не выполнялась или уже завершилась,
· Несуществующая (non-existent) - не существует в системе, или не создавалась, или уже уничтожена.
Планирование задач основано на приоритетах, присвоенных задачам, и является вытесняющим (preemptive). Совокупность задач с одинаковым приоритетом обслуживается по принципу - “первый пришел, первым обслужен” (FCFS - first come, first served).
Управление задачами. Функции управления задачами включают создание и уничтожение задачи, активацию и завершение задачи, отмену запросов на активацию и получение информации о состоянии задачи. Задача является объектом с уникальным идентификатором (ID).
Обработка прерываний. В спецификации µITRON4.0 обработка внешних прерываний производится с помощью обработчиков прерываний (interrupt handlers) и программ обслуживания прерываний (interrupt service routines). Обработчики прерываний управляют устройствами IRC (Interrupt Request Controller) и зависят от архитектуры прерываний процессора. Они не могут быть перенесены на другие платформы без изменений. Программы обслуживания прерываний запускаются обработчиками прерываний; они были введены в спецификации µITRON4.0 для улучшения переносимости обработки прерываний.
Спецификация µITRON4.0 определяет интерфейсы приложения для регистрации обработчика прерываний и интерфейсы приложения для программы обслуживания прерываний. Реализация должна обеспечивать либо один набор интерфейсов, либо оба. Если обеспечиваются интерфейсы только для регистрации обработчика прерываний, ядро может обеспечить связующую программу для обработчика прерываний, которая включает процессы, запускающиеся до и после выполнения обработчика прерываний. Если обеспечиваются интерфейсы только для регистрации программы обслуживания прерываний, ядро должно обеспечить для этой программы обработчик прерываний. Поведение системы с использованием обоих интерфейсов определяется реализацией.
Ядро не управляет прерываниями с приоритетами выше порогового приоритетного уровня. Такие прерывания называются неядерными прерываниями. Метод определения порогового приоритетного уровня определяется реализацией. Из обработчиков прерываний, запущенных неядерными прерываниями, нельзя сделать сервисный вызов (вызов функции ядра или программного компонента).
В спецификации µITRON4.0 существует два способа для указания прерывания - с помощью номера прерывания и через номер обработчика прерывания. К тому же программа обслуживания прерывания идентифицируется уникальным идентификатором объекта (ID).
Управление исключительными ситуациями. Спецификация µITRON4.0 определяет управление исключительными ситуациями центрального процессора (CPU) и функции управления исключительными ситуациями на уровне задач.
Обработчик исключительных ситуаций CPU запускается, когда процессор обнаруживает исключительную ситуацию. Обработчик исключительных ситуаций CPU может быть зарегистрирован приложением для каждого вида исключительной ситуации CPU. Ядро может обеспечивать для обработчика исключительной ситуации CPU связующую программу (glue routine), которая включает процессы, запускаемые до и после выполнения обработчика исключительной ситуации CPU.
Поскольку обработчики исключительных ситуаций CPU являются общими для всей системы, контекст и состояние в точке возникновения исключительной ситуации CPU исследуются самим обработчиком исключительной ситуации CPU. Если исключительная ситуация CPU возникает в задаче, обработчик исключительной ситуации CPU может позволить провести обработку этой исключительной ситуации соответствующей программе задачи.
Функции управления исключительными ситуациями задачи используются для остановки нормального выполнения задачи и запуска ее программы обработки исключительной ситуации; эта программа которая выполняется в контексте данной задачи. После возвращения из этой программы будет продолжено прерванное выполнение задачи. Приложение может зарегистрировать для каждой задачи одну программу управления исключительными ситуациями.
Обработчик исключительных ситуаций CPU определяется реализацией, поскольку сильно зависит от архитектуры управления исключительными ситуациями и реализации ядра. Он не переносим на другие платформы.
Сервисные вызовы, которые могут быть встретиться в обработчике исключительных ситуаций CPU, определяются реализацией. Однако обработчик исключительных ситуаций CPU должен выполнять следующие операции (метод выполнения определяется реализацией):
· Читать контекст и системное состояние при возникновении исключительной ситуации CPU. Ядро должно обеспечивать метод ссылки к информации о системном состоянии.
· Читать ID задачи, в которой возникла исключительная ситуация CPU.
· Запросить управление исключительными ситуациями задачи.
Контекст и системное состояние. В спецификации µITRON4.0 ядро управляет выполнением следующих единиц обработки:
· Обработчики прерываний.
· Программы обслуживания прерываний.
· Обработчики временных событий.
· Обработчики исключительных ситуаций CPU.
· Программы расширенных сервисных вызовов.
· Задачи.
· Программы управления исключительными ситуациями задачи.
Обработчики прерываний и программы обслуживания прерываний выполняются в своих собственных независимых контекстах.
Обработчики временных событий запускаются по временному триггеру и выполняются в своих собственных независимых контекстах. Рассматриваются три вида обработчиков временных событий - циклические, аварийные и по переполнению.
Обработчики исключительных ситуаций CPU выполняются в независимом контексте, определяемом исключительной ситуацией CPU и контекстом, в котором возникла исключительная ситуация.
Программы расширенных сервисных вызовов регистрируются приложением и запускаются расширенными сервисными вызовами. Программа расширенного сервисного вызова выполняется в независимом контексте, определяемом расширенным сервисным вызовом и контекстом, из которого произошел этот вызов.
Задачи выполняются в своих собственных независимых контекстах. Программа управления исключительными ситуациями задачи выполняется в ассоциированном контексте задачи.
Процессы ядра не классифицируются как единицы обработки, упомянутые выше. Процессы ядра включают выполнение сервисных вызовов, диспетчер, связующие программы для обработчиков прерываний (или программ обслуживания прерываний), связующие программы для обработчиков исключительных ситуаций CPU. Контекст выполнения процессов ядра никак не влияет на поведение приложения.
Порядок выполнения каждой единицы обработки специфицируется следующим образом:
1. Обработчики прерываний, обработчики временных событий, обработчики исключительных ситуаций CPU
2. Диспетчер (процесс ядра)
3. Задачи
Порядок предшествования в первой группе определяется реализацией. Относительное предшествование задач определяется с помощью правил планирования.
Сервисные вызовы ядра, главным образом, выполняются атомарно, и состояние действующих процессов сервисных вызовов скрыто. Однако реализация может изменить это положение, чтобы улучшить реакцию системы. В этом случае операция сервисного вызова должна все же выполняться атомарно, насколько приложение может определить использование сервисного вызова. Такое поведение называется гарантией атомарности сервисного вызова. Однако иногда это трудно гарантировать при наличии интенсивного взаимодействия с реализационно-зависимыми функциями, которые не покрываются данной спецификацией. В таком случае разрешается ослабление атомарности сервисного вызова.
При атомарном выполнении сервисных вызовов их уровень предшествования является самым высоким. При ослаблении атомарности уровень предшествования сервисных вызовов становится реализационно-зависимым до тех пор, пока их он выше приоритета единицы обработки, вызвавшей эти сервисные вызовы.
Другие процессы ядра, такие как диспетчер и связующие программы для обработчиков прерываний и исключительных ситуаций, обрабатываются аналогично.
Состояние CPU может быть блокированным или разблокированным. В спецификации µITRON4.0 блокированное состояние CPU рассматривается как состояние, независимое от прерываний и диспетчеризации задач. В блокированном состоянии CPU могут быть вызваны только несколько сервисных вызовов.
В заблокированном состоянии обработчики прерываний (за исключением тех, которые были запущены неядерным прерыванием) и обработчики временных событий не запускаются, и диспетчеризация не совершается. Блокированное состояние CPU можно рассматривать как состояние, в котором уровень предшествования выполняющейся единицы обработки является наивысшим. Возможно существование и промежуточного состояния, которое не является ни блокированным, ни разблокированным, - такая реализация тоже имеет место.
Состояние CPU после запуска обработчика прерывания является реализационно-зависимым. Однако то, каким образом можно попасть в разблокированное состояние, определяется реализацией обработчиков прерываний. В реализации определяется также и то, как можно корректно вернуться из обработчиков прерываний после того, как система перешла в разблокированное состояние. Поведение считается не определенным, если обработчики прерываний не делают возврат так, как специфицировано в реализации.
После запуска программ обслуживания прерываний и обработчиков временных событий система переходит в разблокированное состояние. При возврате из этих программ, система также должна быть в разблокированном состоянии. Поведение считается не определенным, если система после возврата из них оказалась в блокированном состоянии.
Запуск обработчиков исключительных ситуаций CPU и возврат из них не изменяют состояния CPU. Если состояние изменяется в обработчике исключительной ситуации CPU, его следует возвращать в предыдущее состояние перед возвратом из обработчика. Поведение считается не определенным, если это не совершается.
Запуск и возврат из программ расширенных сервисных вызовов не изменяют состояния CPU.
После запуска задачи система находится в разблокированном состоянии. После ее окончания система должна быть в разблокированном состоянии. Поведение считается не определенным, если задача закончилась, а система осталась в блокированном состоянии.
Запуск и возврат из программ управления исключительными состояниями задачи не изменяют состояния CPU. Однако не специфицируется, в каком состоянии были запущены программы управления исключительными состояниями задачи. После возврата из программы состояние CPU остается тем же самым, как установлено программой.
Прерывания обычно (но не всегда) разрешены в разблокированном состоянии CPU.
Диспетчеризация может пребывать в двух состояниях - разрешенном или запрещенном. В запрещенном состоянии диспетчеризация не совершается. Запрещенное состояние диспетчеризации может рассматриваться как состояние, в котором уровень предшествования выполняющейся единицы обработки выше, чем у диспетчера. Реализация может допускать существование промежуточного состояния.
Переход к запрещенному состоянию диспетчеризации называется “отключением диспетчеризации”, переход к разрешенному состоянию диспетчеризации называется “включением диспетчеризации”.
В запрещенном состоянии диспетчеризации сервисные вызовы, которые могут быть вызваны из контекста задачи, имеют следующие ограничения. Если сервисный вызов, вызванный в запрещенном состоянии диспетчеризации, привел к тому, что вызвавшая его задача перешла в блокированное состояние, поведение считается не определенным, если не специфировано иное. Сервисные вызовы, вызванные из незадачного контекста, не имеют ограничений даже в запрещенном состоянии диспетчеризации.
Запуск и возврат из обработчиков прерываний, программ обслуживания прерываний, обработчиков временных событий и исключительных ситуаций CPU не изменяют состояния диспетчеризации. Поведение считается не определенным, если при возврате из этих обработчиков/программ состояние диспетчеризации не возвращается в предыдущее состояние.
Запуск и возврат из программ расширенных сервисных вызовов не изменяют состояния диспетчеризации.
После запуска задачи систем находится в разрешенном состоянии диспетчеризации. После окончания задачи система должна быть в разрешенном состоянии диспетчеризации. Поведение считается не определенным, если задача заканчивается в запрещенном состоянии диспетчеризации.
Запуск и возврат из программ управления исключительными состояниями задачи не изменяют состояния диспетчеризации.
Состояние диспетчеризации рассматривается независимо от состояния CPU.
В спецификации µITRON4.0 не существует сервисных вызовов в незадачном контексте, которые изменяют состояние диспетчеризации. Следовательно, невозможно изменить состояние диспетчеризации внутри обработчиков прерываний и временных событий, если это не обеспечивается реализационно-зависимым расширением. Эти правила распространяются и на обработчики исключительных ситуаций CPU, когда они выполняются в незадачном контексте.
Диспетчеризация не производится во время выполнения единицы обработки с более высоким уровнем предшествования, чем у диспетчера, в заблокированном состоянии CPU или в запрещенном состоянии диспетчеризации. Эти три состояния называются состоянием задержки диспетчеризации. Состояние задачи во время задержки диспетчеризации можно изменить только с помощью реализационно-зависимымых расширений. Такие расширения могут делать сервисные вызовы из незадачного контекста, что позволит перевести задачу из состояния “выполняющаяся” в состояние “приостановленная” или “спящая”. Кроме того, расширения могут позволять сервисным вызовам выводить задачу из состояния “приостановленная” в запрещенном состоянии диспетчеризации.
Если задачу в состоянии “выполняющаяся” нужно перевести в состояние “приостановленная” или “спящая”, переход задерживается до тех пор, пока система не выполнит диспетчеризацию. Во время этой задержки считается, что выполняющаяся задача находится в промежуточном состоянии. Интерпретация задачи в этом промежуточном состоянии зависит от реализации. Задача, которая должна поступить следующей на выполнение, остается в состоянии “готова” до тех пор, пока не произойдет диспетчеризация.
Сервисные вызовы классифицируются в следующие три категории:
· Сервисные вызовы для незадачных контекстов.
· Сервисные вызовы, которые могут быть вызваны из любых контекстов.
· Сервисные вызовы для задачных контекстов.
Выполнение сервисных вызовов из незадачных контекстов может быть отложено до тех пор, пока не закончится выполнение единиц обработки с более высоким уровнем предшествования, чем у диспетчера. Это позволяет гарантировать атомарность системных вызовов без запрещения прерываний на слишком долгое время. Такой подход называется отложенным выполнением сервисных вызовов. Однако существует группа сервисных вызовов, для которых не разрешается откладывание их выполнения.
В спецификации µITRON4.0 специфицируется процедура инициализации системы, а также процедуры регистрации объектов и их уничтожения. Объект обладает уникальным идентификатором и регистрируется ядром с помощью статического вызова некоторого метода интерфейса приложения или сервисного вызова, которые создают этот объект.
В спецификации µITRON4.0 определяется формат написания на языке C следующих единиц обработки: программ обслуживания прерываний, обработчиков временных событий, программ расширенных сервисных вызовов, задач и программ управления исключительными ситуациями задачи. Однако не специфицируется формат написания единиц обработки на языке ассемблера. Формат для написания обработчиков прерываний, обработчиков исключительных ситуаций CPU и атрибутов объектов, которые используются для их регистрации в ядре, определяются реализацией и не определяется в спецификации µITRON4.0.
С целью улучшения переносимости приложений в них могут использоваться константы и макросы, описывающие конфигурацию ядра,. Метод, который используется для определения констант и макросов конфигурации ядра, является реализацинннно-зависимым. Обычно они определяются в заголовочных файлах ядра или могут быть сгенерированы конфигуратором. Как альтернатива, они могут быть определены в заголовочных файлах приложения и затем использованы для конфигурации ядра.
3.2 Windows CE
Системы семейства 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 поддерживает обобщенные функции ожидания для различных типов объектов (мьютексов, семафоров, событий, процессов и потоков). Преимущество таких функций состоит в том, что можно ожидать многие объекты сразу, пока один из них не подаст сигнал. Критические секции можно использовать только внутри одного процесса. Вычислительные семафоры и мьютексы могут быть использованы как внутри одного процесса, так и между процессами.
Подобные документы
Классификация систем реального времени. Ядра и операционные системы реального времени. Задачи, процессы, потоки. Преимущества и недостатки потоков. Свойства, планирование, синхронизация задач. Связанные задачи. Синхронизация с внешними событиями.
реферат [391,5 K], добавлен 28.12.2007Основные характеристики систем реального времени, типы архитектур. Система приоритетов процессов (задач) и алгоритмы диспетчеризации. Понятие отказоустойчивости, причины сбоев. Отказоустойчивость в существующих системах реального времени (QNX Neutrino).
контрольная работа [428,8 K], добавлен 09.03.2013Операционные системы пакетной обработки, разделения времени, реального времени. Особенности алгоритмов управления ресурсами. Поддержка многопользовательского режима. Вытесняющая и невытесняющая многозадачность. Операционные системы и глобальные сети.
реферат [55,0 K], добавлен 11.12.2011Характеристики, основы применения, архитектура жестких и операционных систем реального времени. Последовательное программирование задач реального времени. Структура и языки параллельного программирования, мультипрограммирования и многозадачности.
курсовая работа [195,9 K], добавлен 17.12.2015Обзор требований проблемной области. Особенности управления задачами. Исполнительные системы реального времени. Программирование на уровне микропроцессоров. Модели и методы предметной области. Реализация прототипа системы реального времени.
курсовая работа [263,1 K], добавлен 15.02.2005Важность операционной системы для мобильных устройств. Популярность операционных систем. Доля LINUX на рынке операционных систем. История OS Symbian, BlackBerry OS, Palm OS. Отличия смартфона от обычного мобильного телефона. Учет ограничений по памяти.
презентация [477,3 K], добавлен 01.12.2015Характеристика устройств реального времени: принципы их создания, виды, практическое применение к операционным системам для персональных компьютеров. Основные свойства системы LynxOS, поддержка приложений, сетевые возможности. Средства кросс-разработки.
реферат [33,1 K], добавлен 02.12.2013Рассмотрение основных принципов и методов проектирования систем реального времени. Описание конструктивных и функциональных особенностей объекта управления, построение диаграммы задач. Выбор аппаратной архитектуры, модели процессов-потоков, интерфейса.
курсовая работа [1,2 M], добавлен 19.01.2015Планирование задач в операционной системе реального времени. Основные виды планирования применительно к задачам реального времени. Выбор приемлемого алгоритма планирования при проектировании RTS. Статическое прогнозирование с использованием таблиц.
контрольная работа [40,7 K], добавлен 28.05.2014Операційні системи реального часу сімейства VxWorks корпорації WindRiver Systems для розробки програмного забезпечення вбудованих комп'ютерів. Архітектура операційної системи VxWorks клієнт-сервер, побудова у відповідності з технологією мікроядра.
реферат [1,7 M], добавлен 21.05.2010
