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

     При планировании на основе приоритетов  необходимо решить две обязательные проблемы: обеспечить выполнение процесса с наивысшим приоритетом, не допустить инверсии приоритетов, когда задачи с высокими приоритетами ожидают ресурсы, захваченные задачами с более низкими приоритетами. Для борьбы с инверсией приоритетов в ОСРВ часто используется механизм наследования приоритетов, однако при этом приходится отказываться от планирования на основе 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.7. Стандарты безопасности 

     В связи со стандартами для ОСРВ стоит отметить широко известный  стандарт критериев оценки пригодности  компьютерных систем (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 определяется, как полуформально  спроектированный и протестированный. Он предусматривает создание  полуформальной функциональной  спецификации и проекта высокого  уровня с демонстрацией соответствия  между ними, формальной модели политики безопасности, стандартизованной модели жизненного цикла, а также проведение анализа скрытых каналов.