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

Размещено на http://www.allbest.ru/

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

Оглавление

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. Сводные таблицы характеристик свойств ОСРВ

Приложение А. Перечень сокращений

Приложение B. Терминология

Литература

1. Введение: Особенности операционных систем реального времени

Операционные системы реального времени (ОСРВ) предназначены для обеспечения интерфейса к ресурсам критических по времени систем реального времени. Основной задачей в таких системах является своевременность (timeliness) выполнения обработки данных.

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

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

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

Мартин Тиммерман сформулировал следующие необходимые требования для ОСРВ [DEDSYS]:

· ОС должна быть многозадачной и допускающей вытеснение (preemptable),

· ОС должна обладать понятием приоритета для потоков,

· ОС должна поддерживать предсказуемые механизмы синхронизации,

· ОС должна обеспечивать механизм наследования приоритетов,

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

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

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

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

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

Рассмотрим концептуальные абстракции операционной системы через призму требований к системам реального времени.

1.1 Процессы, потоки, задачи

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

Концепция многозадачности (псевдопараллелизм) является существенной для системы реального времени с одним процессором, приложения которой должны быть способны обрабатывать многочисленные внешние события, происходящие практически одновременно. Концепция процесса, пришедшая из мира UNIX, плохо реализуется в многозадачной системе, поскольку процесс имеет тяжелый контекст. Возникает понятие потока (thread), который понимается как подпроцесс, или легковесный процесс (light-weight process). Потоки существуют в одном контексте процесса, поэтому переключение между потоками происходит очень быстро, а вопросы безопасности не принимаются во внимание. Потоки являются легковесными, потому что их регистровый контекст меньше, т.е. их управляющие блоки намного компактнее. Уменьшаются накладные расходы, вызванные сохранением и восстановлением управляющих блоков прерываемых потоков. Объем управляющих блоков зависит от конфигурации памяти. Если потоки выполняются в разных адресных пространствах, система должна поддерживать отображение памяти для каждого набора потоков.

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

1.2 Планирование, приоритеты

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

В связи с проблемами планирования в ОСРВ изучаются и развиваются два подхода - статические алгоритмы планирования (RMS - Rate Monotonic Scheduling) [LL73] и динамические алгоритмы планирования (EDF - Earliest Deadline First).

RMS используется для формального доказательства условий предсказуемости системы. Для реализации этой теории необходимо планирование на основе приоритетов, прерывающих обслуживание (preemptive priority scheduling). В теории RMS приоритет заранее назначается каждому процессу. Процессы должны удовлетворять следующим условиям:

· процесс должен быть завершен за время его периода,

· процессы не зависят друг от друга,

· каждому процессу требуется одинаковое процессорное время на каждом интервале,

· у непериодических процессов нет жестких сроков,

· прерывание процесса происходит за ограниченное время.

Процессы выполняются в соответствии с приоритетами. При планировании RMS предпочтение отдается задачам с самыми короткими периодами выполнения.

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

Во всех системах реального времени требуется политика планирования, управляемая дедлайнами (deadline-driven scheduling). Однако этот подход находится в стадии разработки.

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

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

При планировании на основе приоритетов необходимо решить две обязательные проблемы:

· обеспечить выполнение процесса с наивысшим приоритетом,

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

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

1.3 Память

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

· Модель без защиты - системное и пользовательское адресные пространства не защищены друг от друга, используется два сегмента памяти: для кода и для данных; при этом от системы не требуется никакого управления памятью, не требуется MMU (memory management unit - специальное аппаратное устройство для поддержки управления виртуальной памятью).

· Модель защиты система/пользователь - системное адресное пространство защищено от адресного пространства пользователя, системные и пользовательские процессы выполняются в общем виртуальном адресном пространстве, при этом требуется MMU. Защита обеспечивается страничным механизмом защиты. Различаются системные и пользовательские страницы. Пользовательские приложения никак не защищены друг от друга. Процессор находится в режиме супервизора, если текущий сегмент имеет уровень 0, 1 или 2. Если уровень сегмента - 3, то процессор находится в пользовательском режиме. В этой модели необходимы четыре сегмента - два сегмента на уровне 0 (для кода и данных) и два сегмента на уровне 3. Механизм страничной защиты не добавляет накладных расходов, т.к. защита проверяется одновременно с преобразованием адреса, которое выполняет MMU; при этом ОС не нуждается в управлении памятью.

· Модель защиты пользователь/пользователь - к модели система/пользователь добавляется защита между пользовательскими процессами; требуется MMU. Как и в предыдущей модели, используется механизм страничной защиты. Все страницы помечаются как привилегированные, за исключением страниц текущего процесса, которые помечаются как пользовательские. Таким образом, выполняющийся поток не может обратиться за пределы своего адресного пространства. ОС отвечает за обновление флага привилегированности для конкретной страницы в таблице страниц при переключении процесса. Как и в предыдущей модели используются четыре сегмента.

· Модель защиты виртуальной памяти - каждый процесс выполняется в своей собственной виртуальной памяти, требуется MMU. У каждого процесса имеются свои собственные сегменты и, следовательно, своя таблица описателей. ОС несет ответственность за поддержку таблиц описателей. Адресуемое пространство может превышать размеры физической памяти, если используется страничная организация памяти совместно с подкачкой. Однако в системах реального времени подкачка обычно не применяется из-за ее непредсказуемости. Для решения этой проблемы доступная память разбивается на фиксированное число логических адресных пространств равного размера. Число одновременно выполняющихся процессов в системе становится ограниченным.

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

Если поддерживается страничная организация памяти (paging), соответствующее отображение страниц в физические адреса должно быть частью контекста процесса. Иначе опять появляется непредсказуемость, неприемлемая для ОСРВ.

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

В обычных ОС при использовании механизма сегментации памяти для борьбы с фрагментацией применяется процедура уплотнения после сборки мусора. Однако такой подход неприменим в среде реального времени, т.к. во время уплотнения перемещаемые задачи не могут выполняться, что ведет к непредсказуемости системы. В этом состоит основная проблема применимости объектно-ориентированного подхода к системам реального времени. До тех пор, пока проблема уплотнения не будет решена, C++ и JAVA останутся не самым лучшим выбором для систем жесткого реального времени.

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

1.4 Прерывания

При описании управления прерываниями обычно различают две процедуры, а именно:

· программа обработки прерывания (ISR - interrupt servicing routine) - программа низкого уровня в ядре с ограниченными системными вызовами,

· поток обработки прерывания (IST - interrupt servicing thread) - поток уровня приложения, который управляет прерыванием, с доступом ко всем системным вызовам.

Обычно ISR реализуются производителем аппаратуры, а драйверы устройств выполняют управление прерываниями с помощью IST. Потоки обработки прерываний действуют как любые другие потоки и используют ту же самую систему приоритетов. Это означает, что проектировщик системы может придать IST более низкий приоритет, чем приоритет потока приложения.

1.5 Часы и таймеры

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

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

Большинство ОСРВ оперируют относительным временем. Что-то происходит “до” и “после” некоторого другого события. В системе, полностью управляемой событиями, необходим часовой механизм (ticker), т.к. там нет квантования времени (time slicing). Однако, если нужны временные метки для некоторых событий или необходим системный вызов типа “ждать одну секунду”, то нужен тактовый генератор и/или таймер.

Синхронизация в ОСРВ осуществляется с помощью механизма блокирования (или ожидания) до наступления некоторого события. Абсолютное время не используется.

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

1.6 Стандарты ОСРВ

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

Наиболее ранним и распространенным стандартом ОСРВ является стандарт POSIX (IEEE Portable Operating System Interface for Computer Environments, IEEE 1003.1). Первоначальный вариант стандарта POSIX появился в 1990 г. и был предназначен для UNIX-систем, первые версии которых появились в 70-х годах прошлого века. Спецификации POSIX определяют стандартный механизм взаимодействия прикладной программы и операционной системы и в настоящее время включают набор более чем из 30 стандартов. Для ОСРВ наиболее важны семь из них (1003.1a, 1003.1b, 1003.1c, 1003.1d, 1003.1j, 1003.21, 1003.2h), но широкую поддержку в коммерческих ОС получили только три первых.

Несмотря на явно устаревшие положения стандарта POSIX и большую востребованность обновлений стандартизации для ОСРВ, заметного продвижения в этом направлении не наблюдается.

Некоторые наиболее успешные компании в области систем реального времени объявляют о своем решении принять в качестве стандарта спецификации одной из своих продвинутых ОСРВ. Так поступила компания TRON (the RTOS Nucleus), которая в 1987г. выпустила в свет первые ITRON спецификации - ITRON1. Далее в 1989г. она разработала и выпустила спецификации µITRON для 8- и 16- битовых микроконтроллеров, а также спецификации ITRON2 для 32-битовых процессоров. ОСРВ ITRON описывается ниже в соответствующем разделе. Этот стандарт является очень распространенным в Японии.

Военная и аэрокосмическая отрасли предъявляют жесткие требования к вычислительным средствам, влияющим на степень безопасности целевой системы. В настоящее время имеются следующие стандарты для ОСРВ в авиации - стандарт DO-178B и стандарт ARINC-653. Поскольку эти стандарты разработаны в США, стоит отметить еще европейский стандарт ED-12B, который является аналогом DO-178B.

Распространенным также является стандарт OSEK/VDX [OSEK], который первоначально развивался для систем автомобильной индустрии.

1.6.1 POSIX

Стандарт POSIX был создан как стандартный интерфейс сервисов операционных систем. Этот стандарт дает возможность создавать переносимые приложения. Впоследствии этот стандарт был расширен особенностями режима реального времени [POSIX].

Спецификации POSIX задают стандартный механизм взаимодействия приложения и ОС. Необходимо отметить, что стандарт POSIX тесно связан с ОС Unix; тем не менее, разработчики многих ОСРВ стараются выдержать соответствие этому стандарту. Соответствие стандарту POSIX для ОС и аппаратной платформы должно быть сертифицировано с помощью прогона на них тестовых наборов [POSIXTestSuite]. Однако, если ОС не является Unix-подобной, выдержать это требование становится непростой задачей. Тестовые наборы существуют только для POSIX 1003.1a. Поскольку структура POSIX является совокупностью необязательных возможностей, поставщики ОС могут реализовать только часть стандартного интерфейса, и при этом говорить о POSIX-комплиантности своей системы.

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

К настоящему времени стандарт POSIX рассматривается как семейство родственных стандартов: IEEE Std 1003.n (где n - это номер).

Стандарт 1003.1a (OS Definition) содержит базовые интерфейсы ОС - поддержку единственного процесса, поддержку многих процессов, управление заданиями, сигналами, группами пользователей, файловой системой, файловыми атрибутами, управление файловыми устройствами, блокировками файлов, устройствами ввода/вывода, устройствами специального назначения, системными базами данных, каналами, очередями FIFO, а также поддержку языка C.

Стандарт 1003.1b (Realtime Extensions) содержит расширения реального времени - сигналы реального времени, планирование выполнения (с учетом приоритетов, циклическое планирование), таймеры, синхронный и асинхронный ввод/вывод, ввод/вывод с приоритетами, синхронизация файлов, блокировка памяти, разделяемая память, передача сообщений, семафоры. Чтобы стать POSIX-комплиантной, ОС должна реализовать не менее 32 уровней приоритетов. POSIX определяет три политики планирования обработки процессов:

· SCHED_FIFO - процессы обрабатываются в режиме FIFO и выполняются до завершения,

· SCHED_RR - round robin - каждому процессу выделяется квант времени,

· SCHED_OTHER - произвольная реализационно-зависимая политика, которая не переносима на другие платформы.

Стандарт 1003.1c (Threads) касается функций поддержки многопоточной обработки внутри процесса - управление потоками, планирование с учетом приоритетов, мьютексы (специальные синхронизирующие объекты в межпроцессном взаимодействии, подающие сигнал, когда они не захвачены каким-либо потоком), приоритетное наследование в мьютексах, переменные состояния (condition variables).

Стандарт 1003.1d включает поддержку дополнительных расширений реального времени - семантика порождения новых процессов (spawn), спорадическое серверное планирование, мониторинг процессов и потоков времени выполнения, таймауты функций блокировки, управление устройствами и прерываниями.

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

Стандарт 1003.2h касается сервисов, отвечающих за работоспособность системы.

1.6.2 DO-178B

Стандарт DO-178B, создан Радиотехнической комиссией по аэронавтике (RTCA, Radio Technical Commission for Aeronautics) для разработки ПО бортовых авиационных систем [DO178B]. Первая его версия была принята в 1982 г., вторая (DO-178A) - в 1985-м, текущая DO-178B - в 1992 г. Готовится принятие новой версии, DO-178C. Стандартом предусмотрено пять уровней серьезности отказа, и для каждого из них определен набор требований к программному обеспечению, которые должны гарантировать работоспособность всей системы в целом при возникновении отказов данного уровня серьезности

Данный стандарт определяет следующие уровни сертификации:

· А (катастрофический),

· В (опасный),

· С (существенный),

· D (несущественный)

· Е (не влияющий).

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

1.6.3 ARINC-653

Стандарт ARINC-653 (Avionics Application Software Standard Interface) разработан компанией ARINC в 1997 г. Этот стандарт определяет универсальный программный интерфейс APEX (Application/Executive) между ОС авиационного компьютера и прикладным ПО. Требования к интерфейсу между прикладным ПО и сервисами операционной системы определяются таким образом, чтобы разрешить прикладному ПО контролировать диспетчеризацию, связь и состояние внутренних обрабатываемых элементов. В 2003 г. принята новая редакция этого стандарта. ARINC-653 в качестве одного из основных требований для ОСРВ в авиации вводит архитектуру изолированных (partitioning) виртуальных машин.

1.6.4 OSEK

Стандарт OSEK/VDX является комбинацией стандартов, которые изначально разрабатывались в двух отдельных консорциумах, впоследствии слившихся. OSEK берет свое название от немецкого акронима консорциума, в состав которого входили ведущие немецкие производители автомобилей - BMW, Bosch, Daimler Benz (теперь Daimler Chrysler), Opel, Siemens и Volkswagen, а также университет в Карлсруэ (Германия). Проект VDX (Vehicle Distributed eXecutive) развивался совместными усилиями французских компаний PSA и Renault. Команды OSEK и VDX слились в 1994г.

Первоначально проект OSEK/VDX предназначался для разработки стандарта открытой архитектуры ОС и стандарта API для систем, применяющихся в автомобильной промышленности. Однако разработанный стандарт получился более абстрактным и не ограничивается использованием только в автомобильной индустрии.

Стандарт OSEK/VDX состоит из трех частей - стандарт для операционной системы (OS), коммуникационный стандарт (COM) и стандарт для сетевого менеджера (NM). В дополнение к этим стандартам определяется некий реализационный язык (OIL). Первым компонентом стандарта OSEK является стандарт для ОС, поэтому часто стандарт OSEK ошибочно воспринимается как стандарт ОСРВ. Хотя ОС и есть большая порция данного стандарта, мощность его состоит в интеграции всех его компонент.

В данной работе рассматривается только стандарт для операционной системы, и его описание приводится в разделе 2.7.

1.6.5 Стандарты безопасности

В связи со стандартами для ОСРВ стоит отметить широко известный стандарт критериев оценки пригодности компьютерных систем (Trusted Computer System Evaluation Criteria - TCSEC) [DoD85]. Этот стандарт разработан Министерством обороны США и известен также под названием "Оранжевая книга" (Orange Book - из-за цвета обложки).

В ряде других стран были разработаны аналогичные критерии, на основе которых был создан международный стандарт “Общие критерии оценки безопасности информационных технологий” (далее просто - Общие критерии) (Common Criteria for IT Security Evaluation, ISO/IEC 15408) [CC99].

В "Оранжевой книге" перечислены семь уровней защиты:

· А1 - верифицированная разработка. Этот уровень требует, чтобы защиту секретной и другой критичной информации средствами управления безопасностью гарантировали методы формальной верификации.

· В3 - домены безопасности. Этот уровень предназначен для защиты систем от опытных программистов.

· В2 - структурированная защита. В систему с этим уровнем защиты нельзя допустить проникновение хакеров.

· В1 - мандатный контроль доступа. Защиту этого уровня, возможно, удастся преодолеть опытному хакеру, но никак не рядовым пользователям.

· С2 - дискреционный контроль доступа. Уровень С2 обеспечивает защиту процедур входа, позволяет производить контроль за событиями, имеющими отношение к безопасности, а также изолировать ресурсы.

· С1 - избирательная защита. Этот уровень дает пользователям возможность защитить личные данные или информацию о проекте, установив средства управления доступом.

· D - минимальная защита. Этот нижний уровень защиты оставлен для систем, которые проходили тестирование, но не смогли удовлетворить требованиям более высокого класса.

Что касается Общих критериев, то в них введены похожие требования обеспечения безопасности в виде оценочных уровней (Evaluation Assurance Levels - EAL). Их также семь:

· EAL7 - самый высокий уровень предполагает формальную верификацию модели объекта оценки. Он применим к системам очень высокого риска.

· EAL6 определяется, как полуформально верифицированный и протестированный. На уровне EAL6 реализация должна быть представлена в структурированном виде, анализ соответствия распространяется на проект нижнего уровня, проводится строгий анализ покрытия, анализ и тестирование небезопасных состояний.

· EAL5 определяется, как полуформально спроектированный и протестированный. Он предусматривает создание полуформальной функциональной спецификации и проекта высокого уровня с демонстрацией соответствия между ними, формальной модели политики безопасности, стандартизованной модели жизненного цикла, а также проведение анализа скрытых каналов.

· EAL4 определяется, как методически спроектированный, протестированный и пересмотренный. Он предполагает наличие автоматизации управления конфигурацией, полной спецификации интерфейсов, описательного проекта нижнего уровня, подмножества реализаций функций безопасности, неформальной модели политики безопасности, модели жизненного цикла, анализ валидации, независимый анализ уязвимостей. По всей вероятности, это самый высокий уровень, которого можно достичь на данном этапе развития технологии программирования с приемлемыми затратами.

· EAL3 определяется, как методически протестированный и проверенный. На уровне EAL3 осуществляется более полное, чем на уровне EAL2, тестирование покрытия функций безопасности, а также контроль среды разработки и управление конфигурацией объекта оценки.

· EAL2 определяется, как структурно протестированный. Он предусматривает создание описательного проекта верхнего уровня объекта оценки, описание процедур инсталляции и поставки, руководств администратора и пользователя, функциональное и независимое тестирование, оценку прочности функций безопасности, анализ уязвимостей разработчиками.

· EAL1 определяется, как функционально протестированный. Он обеспечивает анализ функций безопасности с использованием функциональной спецификации и спецификации интерфейсов, руководящей документации, а также независимое тестирование. На этом уровне угрозы не рассматриваются как серьезные.

В соответствии с требованиями Общих критериев, продукты определенного класса (например, операционные системы) оцениваются на соответствие ряду функциональных критериев и критериев доверия - профилей защиты. Существуют различные определения профилей защиты в отношении операционных систем, брандмауэров, смарт-карт и прочих продуктов, которые должны соответствовать определенным требованиям в области безопасности. Например, профиль защиты систем с разграничением доступа (Controlled Access Protection Profile) действует в отношении операционных систем и призван заменить старый уровень защиты С2, определявшийся в соответствии с американским стандартом TCSEC. В соответствии с оценочными уровнями доверия сертификация на соответствие более высокому уровню означает более высокую степень уверенности в том, что система защиты продукта работает правильно и эффективно, и, согласно условиям Общих критериев, уровни 5-7 рассчитаны на тестирование продуктов, созданных с применением специализированных технологий безопасности.

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

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

1.7 Настраиваемость операционных систем

В последнее время одной из главных тем исследовательских работ в области операционных систем стало исследование настраиваемости (customizability) или адаптируемости операционной системы. Настраиваемой или адаптируемой операционной системой называется операционная система, допускающая гибкую модификацию основных механизмов, стратегий и политик системы. В зависимости от контекста, настраиваемость системы может преследовать различные цели. В операционных системах общего назначения, как правило, такой целью является производительность системы в целом. Для встроенных систем настраиваемость служит целям энергосбережения и/или сокращения объема программного обеспечения. Детальный систематический обзор исследовательских операционных систем с точки зрения их настраиваемости дается в работе Дениса и др. [DPM02].

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

2. Краткие характеристики наиболее распространенных ОСРВ

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

2.1 VxWorks

Операционные системы реального времени семейства VxWorks корпорации WindRiver Systems предназначены для разработки программного обеспечения (ПО) встраиваемых компьютеров, работающих в системах жесткого реального времени [VxWorks]. Операционная система VxWorks обладает кросс-средствами разработки программного обеспечения (ПО), т.е. разработка ведется на инструментальном компьютере (host) в среде Tornado для дальнейшего ее использования на целевом компьютере (target) под управлением системы VxWorks.

Операционная система VxWorks имеет архитектуру клиент-сервер и построена в соответствии с технологией микроядра, т.е. на самом нижнем непрерываемом уровне ядра (WIND Microkernel) обрабатываются только планирование задач и управление их взаимодействием/синхронизацией. Вся остальная функциональность операционного ядра - управление памятью, вводом/выводом и пр. - обеспечивается на более высоком уровне и реализуется через процессы. Это обеспечивает быстродействие и детерминированность ядра, а также масштабируемость системы.

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

Хотя система VxWorks является конфигурируемой, т.е. отдельные модули можно загружать статически или динамически, нельзя сказать, что в ней используется подход, основанный на компонентах. Все модули построены над базовым ядром и спроектированы таким образом, что не могут использоваться в других средах.

Ядро VxWorks обладает следующими параметрами:

· количество задач не ограничено,

· число уровней приоритетов задач - 256,

· планирование задач возможно двумя способами - вытеснение по приоритетам и циклическое,

· средствами взаимодействия задач служат очереди сообщений, семафоры, события и каналы (для взаимодействия задач внутри CPU), сокеты и удаленные вызовы процедур (для сетевого взаимодействия), сигналы (для управления исключительными ситуациями) и разделяемая память (для разделения данных),

· для управления критическими системными ресурсами обеспечивается несколько типов семафоров: двоичные, вычислительные (counting) и взаимно исключающие с приоритетным наследованием,

· поддерживается детерминированное переключение контекста.

В VxWorks обеспечивается как основанный на POSIX, так и собственный механизмы планирования (wind scheduling). Оба варианта включают вытесняющее и циклическое планирование. Различие между ними состоит в том, что wind scheduling применяется на системном базисе, в то время как алгоритмы POSIX-планирования применяются на базисе процесс-за-процессом.

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

Чтобы достичь быстрой обработки внешних прерываний, программы обработки прерываний (ISRs - interrupt service routines) в VxWorks выполняются в специальном контексте вне контекстов потоков, что позволяет выиграть время, которое обычно тратится на переключение контекстов. Следует отметить, что C-функция, которую пользователь присоединяет к вектору прерывания, на самом деле не является фактической ISR. Прерывания не могут непосредственно обращаться к C-функциям. Адрес ISR запоминается в таблице векторов прерываний, которая вызывается аппаратно. ISR выполняет некую начальную обработку (сохранение регистров и подготовку стека), а затем вызывается C-функция, которая была присоединена пользователем.

VSPWorks [VSPWorks] - это весьма популярная и достаточно мощная ОС на основе VxWorks. VSPWorks спроектирована специально для систем, основанных на DSP. Она обеспечивает многозадачный режим с приоритетами и поддержку быстрых прерываний на процессорах DSP и ASIC. ОСРВ VSPWorks следует модели единственного виртуального процессора, что значительно упрощает распределение приложений в многопроцессорной системе, сохраняя при этом производительность жесткого реального времени. VSPWorks является модульной и масштабируемой.

ОСРВ VSPWorks обладает многослойной структурой, что служит хорошей основой для абстрагирования и переносимости. Центром системы служит сильно оптимизированное наноядро (nanokernel), которое способно управлять совокупностью процессов. Ниже наноядра находятся программы, обслуживающие прерывания, выше наноядра располагается микроядро, которое управляет многозадачным режимом с приоритетами C/C++ задач.



Рис. 1. Многослойная архитектура VSPWorks.

Управление прерываниями имеет два уровня. Нижний уровень (уровень 1) используется для обработки аппаратных прерываний. Во время обработки таких прерываний все остальные прерывания блокируются. Код, выполняющийся на этом уровне, написан на языке ассемблера, и ответственность за сохранение соответствующих регистров в стеке ложится на программиста. На этом уровне может быть обработано прерывание, которое требует малого времени для обработки. Если обработка прерывания является более сложной и требует большего времени, то прерывание обрабатывается на более высоком уровне (уровень 2), где разрешено прерывание прерывания и, таким образом, они могут быть вложенными. Переход на более высокий уровень прерываний происходит по системному вызову.

Процессы наноядра (уровень 3) пишутся на языке ассемблера и имеют сокращенный контекст (т.е. используют меньше регистров). Эти процессы могут быть загружены и разгружены с процессора очень быстро. Каждому процессу присваивается приоритет. Уровень 3 идеален для написания драйверов для интерфейсов аппаратуры низкого уровня.

Микроядро находится на уровне 4. Микроядро написано на языке C и имеет свыше 100 сервисов. Обработка задач на этом уровне ведется в режиме приоритетного прерывания, и планирование управляется приоритетами.

Сетевые средства. VxWorks поддерживает все сетевые средства, стандартные для UNIX: TCP/zero-copyTCP/UDP/ICMP/IP/ARP, SLIP/CSLIP/PPP, Sockets, telnet/rlogin/rpc/rsh, ftp/tftp/bootp, NFS (Network File System) (клиент и сервер). В сетевые средства для VxWorks входят также функции, необходимые при разработке устройств, подключаемых к Internet: IP multicasting уровня 0,1 или 2; long fat pipe; CIDR (Classless Inter-Domain Routing); DHCP (Dynamic Host Configuration Protocol) в конфигурациях server, client и relay agent; DNS client (Domain Naming System); SNTP (Simple Network Time Protocol). VxWorks поддерживает протоколы маршрутизации RIPv1/RIPv2 (Routing Information Protocol), а также OSPF (Open Shortest Path First) версии 2. Протокол RIP входит в стандартную поставку VxWorks, OSPF поставляется как дополнительный продукт. SNMP-агент для VxWorks поддерживает протокол SNMP (Simple Network Management Protocol) как версии v1, так и v2c. MIB (Management Information Base) компилятор поддерживает объекты MIB-II и расширения. STREAMS - стандартный интерфейс для подключения переносимых сетевых протоколов к операционным системам. В среде VxWorks можно инсталлировать любой протокол, имеющий STREAMS-реализацию: как стандартный (Novell SPX/IPX, Decnet, AppleTalk, SNA и т.п.), так и специализированный. VxWorks поддерживает STREAMS версии UNIX System V.4.

Графические пакеты и встроенный Интернет. Графические приложения для встраиваемых компьютеров с ОСРВ VxWorks могут быть разработаны как на языке С/С++, так и на языках Java и HTML. Для разработки графических пользовательских интерфейсов (GUI) на языке C++ поставляется программный продукт Zinc for VxWorks, для разработки на языке Java - PersonalJWorks и для разработки на языке HTML - HTMLWorks/eNavigator. Все три GUI для VxWorks используют один и тот же универсальный API к графической аппаратуре (графическому контроллеру, фрэйм-буферу и устройству ввода), который называется UGL (Universal Graphics Library). UGL - это набор графических 2D примитивов, драйверы популярных графических контроллеров и средства разработки собственных пользовательских графических драйверов. UGL входит в состав каждого GUI-продукта и поставляется в исходных текстах.

Zinc for VxWorks - это C++ API, предоставляющий широкий набор графических объектов с задаваемыми пользователем параметрами. Для разработки GUI используется Zinc Designer - WYSIWYG-редактор, который входит в комплект поставки. Графический интерфейс может быть разработан на языке Java с использованием стандартного инструментария pAWT (Abstract Windowing Toolkit), входящего в состав PersonalJWorks. Для разработки GUI используется любой инструментарий разработки Java-приложений. Пользовательский интерфейс может быть разработан с использованием графических возможностей языка HTML (фреймы, изображения, таблицы, формы) и динамических возможностей JavaScript. HTMLWorks - это интерпретатор HTML/JavaScript-страниц, которые могут находиться в постоянной памяти или быть загружены по сети. Для разработки GUI используется любой инструментарий web-дизайна. Если встраиваемый компьютер с HTML GUI должен уметь выполнять web-серфинг, то совместно с HTMLWorks может быть использован браузер для встраиваемых приложений eNavigator.

Средства построения мультипроцессорных систем. VxWorks поддерживает два вида мультипроцессинга: слабосвязанный - через распределенные очереди сообщений и сильносвязанный - через объекты в разделяемой памяти. Слабосвязанный мультипроцессинг через распределенные очереди сообщений реализован в библиотеке VxFusion, которая является отдельным продуктом. VxFusion применяется для обмена между процессорами, не имеющими общей памяти (например, между узлами сети). Сильносвязанный мультипроцессинг через объекты в разделяемой памяти реализован в библиотеке VxMP, которая также является отдельным продуктом. VxMP применяется для обмена между процессорами, имеющими общую область памяти (например, находящимися на одной шине).

Средства портирования. Все аппаратно-зависимые части VxWorks вынесены в отдельные модули для того, чтобы разработчик встраиваемой компьютерной системы мог сам портировать VxWorks на свой нестандартный целевой компьютер. Этот комплект конфигурационных и инициализационных модулей называется BSP (Board Support Package) и поставляется для стандартных компьютеров (VME-процессор, PC или Sparcstation) в исходных текстах. Разработчик нестандартного компьютера может взять за образец BSP наиболее близкого по архитектуре стандартного компьютера и портировать VxWorks на свой компьютер путем разработки собственного BSP с помощью BSP Developer's Kit.

Промежуточное ПО (middleware). Модель компонентных объектов COM (Component Object Model) и ее расширение для распределенных систем DCOM (Distributed COM) являются стандартными интерфейсами обмена между приложениями для Windows. VxDCOM - DCOM для операционной системы VxWorks - это первая реализация модели распределенных компонентных объектов для систем реального времени. Теперь нет необходимости в разработке специализированных драйверов ввода/вывода при интеграции нижнего и верхних уровней распределенной системы управления. VxDCOM поддерживает также OPC-интерфейсы (OLE for Process Control), что позволяет разрабатывать OPC-серверы для встраиваемых систем, работающих под управлением ОСРВ VxWorks.

Файловая система для флэш-памяти. Файловая система TrueFFS предназначена для эмуляции жесткого диска, работающего под управлением файловых систем VxWorks: DOS-FS и NFS (Network File System). TrueFFS удовлетворяет стандарту PCMCIA FTL (Flash Translation Level) и поддерживает PC-cards, MiniatureCards и микросхемы флэш-памяти Intel 28F0xx, AMD 29F0xx, и Samsung 29Vxx000.

2.2 QNX Neutrino RTOS

Операционная система QNX Neutrino Realtime Operating System (RTOS) [QNXNeutrino] корпорации QNX Software Systems является микроядерной операционной системой, которая обеспечивает многозадачный режим с приоритетами. QNX Neutrino RTOS имеет клиент-серверную архитектуру. В среде QNX Neutrino каждый драйвер, приложение, протокол и файловая система выполняются вне ядра, в защищенном адресном пространстве. В случае сбоя любого компонента он может автоматически перезапуститься без влияния на другие компоненты или ядро. Хотя система QNX является конфигурируемой, т.е. отдельные модули можно загружать статически или динамически, нельзя сказать, что она использует подход, основанный на компонентах. Все модули полагаются на базовое ядро и спроектированы таким образом, что не могут использоваться в других средах.

QNX Neutrino RTOS состоит из ядра, планировщика процессов (process manager) и расширенных сервисов на уровне пользователя. Как истинная микроядерная операционная система, QNX Neutrino RTOS реализует в ядре ОС только наиболее фундаментальные сервисы, такие как передача сообщений, сигналы, таймеры, планирование потоков, объекты синхронизации. Все другие сервисы ОС, драйверы и приложения выполняются как отдельные процессы, которые взаимодействуют через синхронную передачу сообщений.

Ядро QNX Neutrino RTOS выполняется на уровне 0, управляющие программы и драйверы устройств выполняются на уровнях 1 и 2, совершая операции ввода/вывода. Приложения выполняются на уровне 3.

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

Обладая вытесняющим микроядром и планировщиком с приоритетным обслуживанием, QNX Neutrino RTOS способна быстро и с высокой предсказуемостью реагировать на события реального времени. Высокоприоритетные потоки обрабатывают дедлайны своевременно даже при большой загрузке системы (см. рис. 2)

Рис. 2. Производительность реального времени QNX Neutrino RTOS.

QNX Neutrino RTOS имеет малые времена обработки прерываний, быстрое переключение контекстов. Инверсия приоритетов преодолевается с помощью распределенного наследования приоритетов. Упрощенное моделирование активностей реального времени проводится через синхронную передачу сообщений. Вложенные прерывания и фиксированная верхняя граница времени обработки прерывания гарантируют, что высокоприоритетные прерывания обрабатываются быстро с предсказуемым временем.

2.3 RTEMS

RTEMS (Real-Time Executive for Multiprocessor Systems) - это некоммерческая операционная система реального времени для глубоко встраиваемых систем [RTEMS]. Разработчик системы компания OAR (On-Line Applications Research Corporation, США). Система была создана по заказу министерства обороны США для использования в системах управления ракетными комплексами. Система разрабатывается для многопроцессорных систем на основе открытого исходного кода в противовес аналогичным системам с закрытым кодом. Система рассчитана на платформы MS-Windows и Unix (GNU/Linux, FreeBSD, Solaris, MacOS X).