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




страница1/10
Дата20.04.2017
Размер1.03 Mb.
Просмотров976
Скачиваний0
  1   2   3   4   5   6   7   8   9   10

1
Операционные системы реального
времени
И.Б. Бурдонов, А.С. Косачев, В.Н. Пономаренко
1. Введение: Особенности операционных систем
реального времени
Операционные системы реального времени (ОСРВ) предназначены для обеспечения интерфейса к ресурсам критических по времени систем реального времени. Основной задачей в таких системах является своевременность
(timeliness) выполнения обработки данных.
В качестве основного требования к ОСРВ выдвигается требование обеспечения
предсказуемости или детерминированности поведения системы в наихудших внешних условиях, что резко отличается от требований к производительности и быстродействию универсальных ОС. Хорошая ОСРВ имеет предсказуемое поведение при всех сценариях системной загрузки
(одновременные прерывания и выполнение потоков).
Существует некое различие между системами реального времени и встроенными системами. Не всегда от встроенной системы требуется, чтобы она имела предсказуемое поведение, и в таком случае она не является системой реального времени. Однако даже беглый взгляд на возможные встроенные системы позволяет утверждать, что большинство встроенных систем нуждается в предсказуемом поведении по крайней мере для некоторой функциональности, и таким образом, эти системы можно отнести к системам реального времени.
Принято различать системы мягкого (soft) и жесткого (hard) реального времени. В системах жесткого реального времени неспособность обеспечить реакцию на какие-либо события в заданное время ведет к отказам и невозможности выполнения поставленной задачи.
В большинстве русскоязычной литературы такие системы называют системами с детерминированным временем. При практическом применении время реакции должно быть минимальным. Системами мягкого реального времени называются системы, не попадающие под определение "жесткие", т.к. в литературе четкого определения для них пока нет. Системы мягкого реального времени могут не успевать решать задачу, но это не приводит к отказу системы в целом. В системах реального времени необходимо введение некоторого директивного срока задачи (в англоязычной литературе – deadline), до которого задача должна обязательно (для систем мягкого реального времени –
2 желательно) выполниться.
Этот директивный срок используется планировщиком задач как для назначения приоритета задачи при ее запуске, так и при выборе задачи на выполнение.
Мартин Тиммерман сформулировал следующие необходимые требования для
ОСРВ [DEDSYS]:

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

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

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

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

поведение ОС должно быть известным и предсказуемым (задержки обработки прерываний, задержки переключения задач, задержки драйверов и т.д.), это значит, что должно быть определено максимальное время отклика во всех сценариях рабочей нагрузки системы.
В течение последних 25-30 лет структура операционных систем эволю- ционировала от монолитной к многослойной структуре ОС и далее к архитектуре клиент-сервер. При монолитной структуре ОС состоит из набора модулей, и изменения одного модуля влияют на другие модули. Чем больше модулей, тем больше хаоса при эксплуатации такой системы. Кроме того, невозможно распределить ОС в многопроцессорной системе. В многослойной структуре изменения одного слоя влияют на соседние слои, кроме того, обращение через слой невозможно. Для систем реального времени должно быть обеспечено прямое обращение к каждому слою ОС, а иногда напрямую к аппаратуре.
Основной идеей клиент-серверной технологии в ОС является сведение базиса
ОС к минимуму (планировщик и примитивы синхронизации). Вся остальная функциональность выносится на другой уровень и реализуется через потоки или задачи. Совокупность таких серверных задач отвечает за системные вызовы. Приложения являются клиентами, которые запрашивают сервисы через системные вызовы.
Клиент-серверная технология позволяет создавать масштабируемые ОС и упрощает распределение в многопроцессорной системе. При эксплуатации системы замена одного модуля не вызывает эффекта “снежного кома”, кроме того, сбой модуля не всегда влечет за собой отказ системы в целом. Появилась возможность динамической загрузки и отгрузки модулей. Главной проблемой в этой модели является защита памяти, поскольку серверные процессы должны быть защищены. При каждом запросе сервиса система должна переключаться с контекста приложения на контекст сервера. При поддержке защиты памяти время переключения с одного процесса на другой увеличивается.
Как правило, большинство современных ОСРВ построены на основе микроядра (kernel или nucleus), которое обеспечивает планирование и диспетчеризацию задач, а также осуществляет их взаимодействие. Несмотря на

3 сведение к минимуму в ядре абстракций ОС, микроядро все же должно иметь представление об абстракции процесса. Все остальные концептуальные абстракции операционных систем вынесены за пределы ядра, вызываются по запросу и выполняются как приложения.
Рассмотрим концептуальные абстракции операционной системы через призму требований к системам реального времени.
1.1. Процессы, потоки, задачи
Концепция многозадачности (псевдо-параллелизм) является существенной для системы реального времени с одним процессором, приложения которой должны быть способны обрабатывать многочисленные внешние события, происходящие практически одновременно. Концепция процесса, пришедшая из мира UNIX, плохо реализуется в многозадачной системе, поскольку процесс имеет тяжелый контекст. Возникает понятие потока (thread), который понимается как подпроцесс или легковесный процесс (light-weight process).
Потоки существуют в одном контексте процесса, поэтому переключение между потоками происходит очень быстро, а вопросов безопасности не существует. Потоки являются легковесными, потому что их регистровый контекст меньше, т.е. их управляющие блоки намного компактнее.
Уменьшаются накладные расходы, вызванные сохранением и восстановлением управляющих блоков прерываемых потоков. Объем управляющих блоков зависит от конфигурации памяти. Если потоки выполняются в разных адресных пространствах, система должна поддерживать отображение памяти для каждого набора потоков.
Итак, в системах реального времени процесс распадается на задачи или потоки. В любом случае каждый процесс рассматривается как приложение.
Между этими приложениями не должно быть слишком много взаимодействий, и в большинстве случаев они имеют различную природу – жесткого реального времени, мягкого реального времени, не реального времени.
1.2. Планирование, приоритеты
В связи с проблемой дедлайнов главной проблемой в ОСРВ становится планирование задач (scheduling), которое обеспечивало бы предсказуемое поведение системы при всех обстоятельствах. Процесс с дедлайнами должен стартовать и выполняться так, чтобы он не пропустил ни одного своего дедлайна. Если это невозможно, процесс должен быть отклонен.
В связи с проблемами планирования в ОСРВ изучаются и развиваются два подхода – статические алгоритмы планирования (RMS – Rate Monotonic
Scheduling) [LL73] и динамические алгоритмы планирования (EDF – Earliest
Deadline First).
RMS используется для формального доказательства условий предсказуемости системы. Для реализации этой теории необходимо планирование на основе приоритетов прерывающих обслуживание (preemptive priority scheduling). В теории RMS приоритет заранее назначается каждому процессу. Процессы должны удовлетворять следующим условиям:
4

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

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

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

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

прерывание процесса происходит за ограниченное время.
Процессы выполняются по приоритету. При планировании RMS предпочтение отдается задачам с самыми короткими периодами выполнения.
В EDF приоритет присваивается динамически, и наибольший приоритет выставляется процессу, у которого осталось наименьшее время выполнения.
При больших загрузках системы EDF имеет преимущества перед RMS.
Во всех системах реального времени требуется политика планирования, управляемая дедлайнами (deadline-driven scheduling). Однако этот подход находится в стадии разработки.
Обычно в ОСРВ используется планирование с приоритетами, прерывающими обслуживание, которое основано на RMS. Приоритетное прерывание обслуживания (preemption) является неотъемлемой составляющей ОСРВ, т.к. в системе реального времени должны существовать гарантии того, что событие с высоким приоритетом будет обработано перед событием более низкого приоритета. Все это ведет к тому, что ОСРВ нуждается не только в механизме планирования на основе приоритетов, прерывающих обслуживание, но также и в соответствующем механизме управления прерываниями. Более того, ОСРВ должна быть способна запрещать прерывания, когда необходимо выполнить критический код, который нельзя прерывать. Длительность обработки прерываний должна быть сведена к минимуму.
ОСРВ должна обладать развитой системой приоритетов. Во-первых, потому, что система сама может рассматриваться как набор серверных приложений, подразделяющихся на потоки, и несколько высоких уровней приоритетов должно быть выделено системным процессам и потокам. Во-вторых, в сложных приложениях необходимо все потоки реального времени помещать на разные приоритетные уровни, а потоки не реального времени помещать на один уровень (ниже, чем любые потоки реального времени). При этом потоки не реального времени можно обрабатывать в режиме циклического планирования (RRS – round-robin scheduling), при котором каждому процессу предоставляется квант времени процессора, а когда квант заканчивается, его контекст сохраняется, и процесс ставится в конец очереди. Многие ОСРВ используют RRS для планирования задач на одном уровне. Приоритетный уровень 0 обычно используется для холостого режима.
При планировании на основе приоритетов необходимо решить две обязательные проблемы:

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

5

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

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

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

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

Модель защиты виртуальной памяти – каждый процесс выполняется в своей собственной виртуальной памяти, требуется
MMU. Каждый процесс имеет свои собственные сегменты и, следовательно, свою таблицу описателей. ОС несет ответственность за поддержку таблиц описателей. Адресуемое пространство может превышать размеры физической памяти, если используется страничная организация памяти совместно с подкачкой. Однако в системах реального времени подкачка обычно не применяется из-за ее непредсказуемости. Для решения этой проблемы доступная память разбивается на фиксированное число логических адресных пространств равного размера. Число одновременно выполняющихся процессов в системе становится ограниченным.
Фундаментальное требование для памяти в системе реального времени заключается в том, что время доступа к ней должно быть ограничено (или, другими словами, предсказуемо). Прямым следствием становится запрет на использование техники вызова страниц по запросу (подкачка с диска) для процессов реального времени. Поэтому системы, обеспечивающие механизм виртуальной памяти, должны уметь блокировать процесс в оперативной памяти, не допуская подкачки. Итак, подкачка недопустима в ОСРВ, потому что непредсказуема.
Если поддерживается страничная организация памяти (paging), соответствующее отображение страниц в физические адреса должно быть частью контекста процесса. Иначе опять появляется непредсказуемость, неприемлемая для ОСРВ.
Для процессов, не являющихся процессами жесткого реального времени, возможно использование механизма динамического распределения памяти, однако при этом ОСРВ должна поддерживать обработку таймаута на запрос памяти, т.е. ограничение на предсказуемое время ожидания.
В обычных ОС при использовании механизма сегментации памяти для борьбы с фрагментацией применяется процедура уплотнения после сборки мусора.
Однако такой подход неприменим в среде реального времени, т.к. во время уплотнения перемещаемые задачи не могут выполняться, что ведет к непредсказуемости системы. В этом состоит основная проблема применимости объектно-ориентированного подхода к системам реального времени. До тех пор, пока проблема уплотнения не будет решена, C++ и JAVA останутся не самым лучшим выбором для систем жесткого реального времени.
В системах жесткого реального времени обычно применяется статическое рас- пределение памяти. В системах мягкого реального времени возможно дина- мическое распределение памяти, без виртуальной памяти и без уплотнения.
1.4. Прерывания
При описании управления прерываниями обычно различают две процедуры, а именно:

программа обработки прерывания (ISR – interrupt servicing routine) –

7 программа низкого уровня в ядре с ограниченными системными вызовами,

поток обработки прерывания (IST – interrupt servicing thread) – поток уровня приложения, который управляет прерыванием, с доступом ко всем системным вызовам.
Обычно ISR реализуются производителем аппаратуры, а драйверы устройств выполняют управление прерываниями с помощью IST. Потоки обработки прерываний действуют как любые другие потоки и используют ту же самую систему приоритетов. Это означает, что проектировщик системы может придать IST более низкий приоритет, чем приоритет потока приложения.
1.5. Часы и таймеры
В ОСРВ используются различные службы времени. Операционная система отслеживает текущее время, в определенное время запускает задачи и потоки и приостанавливает их на определенные интервалы. Временные службы ОСРВ используют часы реального времени. Обычно используются высокоточные аппаратные часы. Для отсчета временных интервалов на основе часов реального времени создаются таймеры.
Для каждого процесса и потока определяются часы процессорного времени. На базе этих часов создаются таймеры; которые измеряют перерасход времени процессом или потоком, позволяя динамически выявлять программные ошибки или ошибки вычисления максимально возможного времени выполнения. в высоконадежных, критичных ко времени системах важно выявление ситуаций, при которых задача превышает максимально возможное время своего выполнения, т.к. при этом работа системы может выйти за рамки допустимого времени отклика. Часы времени выполнения позволяют выявить возникновение перерасхода времени и активизировать соответствующие действия по обработке ошибок.
Большинство ОСРВ оперируют относительным временем. Что-то происходит
“до” и “после” некоторого другого события. В системе, полностью управляемой событиями, необходим часовой механизм (ticker), т.к. там нет квантования времени (time slicing). Однако, если нужны временные метки для некоторых событий или необходим системный вызов типа “ждать одну секунду”, тогда нужен тактовый генератор и/или таймер.
Синхронизация в ОСРВ осуществляется с помощью механизма блокирования
(или ожидания) до наступления некоторого события. Абсолютное время не используется.
Реализации в ОСРВ других концептуальных абстракций подобны их реализациям в традиционных ОС.
1.6. Стандарты ОСРВ
Большие различия в спецификациях ОСРВ и огромное количество существующих микроконтроллеров выдвигают на передний план проблему стандартизации в области систем реального.
8
Наиболее ранним и распространенным стандартом ОСРВ является стандарт
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 описана в соответствующем разделе. Этот стандарт является очень распространенным в
Японии. Спецификация 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

9 является совокупностью необязательных возможностей, поставщики ОС могут реализовать только часть стандартного интерфейса, и при этом говорить о
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 касается распределенных систем реального времени и включает функции поддержки распределенного взаимодействия, организации буферизации данных, посылки управляющих блоков, синхронных и асинхронных операций, ограниченной блокировки, приоритетов сообщений, меток сообщений, и реализаций протоколов.
10
Стандарт 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   2   3   4   5   6   7   8   9   10


База данных защищена авторским правом ©nethash.ru 2017
обратиться к администрации

войти | регистрация
    Главная страница


загрузить материал