10463
Операционные системы реального времени. Архитектуры ОСРВ
Реферат
Информатика, кибернетика и программирование
Тема: Операционные системы реального времени. Операционная система реального времени ОСРВ англ. RealTime Operating System тип операционной системы. Есть много определений термина по сути похожих друг на друга. Самые распространённые из них: Операционная система в ...
Русский
2015-01-20
56.33 KB
269 чел.
Тема: «Операционные системы реального времени».
Операционная система реального времени, ОСРВ (англ. Real-Time Operating System) тип операционной системы. Есть много определений термина, по сути похожих друг на друга.
Самые распространённые из них:
Операционные системы реального времени (ОСРВ) предназначены для обеспечения интерфейса к ресурсам критических по времени систем реального времени. Основной задачей в таких системах является своевременность (timeliness) выполнения обработки данных.
В качестве основного требования к ОСРВ выдвигается требование обеспечения предсказуемости или детерминированности поведения системы в наихудших внешних условиях, что резко отличается от требований к производительности и быстродействию универсальных ОС. Хорошая ОСРВ имеет предсказуемое поведение при всех сценариях системной загрузки (одновременные прерывания и выполнение потоков).
Существует некое различие между системами реального времени и встроенными системами. От встроенной системы не всегда требуется, чтобы она имела предсказуемое поведение, и в таком случае она не является системой реального времени. Однако даже беглый взгляд на возможные встроенные системы позволяет утверждать, что большинство встроенных систем нуждается в предсказуемом поведении, по крайней мере, для некоторой функциональности, и таким образом, эти системы можно отнести к системам реального времени.
Операционные системы реального времени иногда делят на два типа системы жесткого реального времени(hard) и системы мягкого реального времени(soft).
Операционная система, которая может обеспечить требуемое время выполнения задачи реального времени даже в худших случаях, называется операционной системой жёсткого реального времени.
Операционная система, которая может обеспечить требуемое время выполнения задачи реального времени в среднем, называется операционной системой мягкого реального времени.
Системы жёсткого реального времени не допускают задержек реакции системы, так как это может привести к:
Если не выполняется обработка критических ситуаций либо она происходит недостаточно быстро, система жёсткого реального времени прерывает операцию и блокирует её, чтобы не пострадала надёжность и готовность остальной части системы. Примерами систем жёсткого реального времени могут быть системы управления бортового оборудования, системы аварийной защиты, регистраторы аварийных событий.
Системы мягкого реального времени характеризуются возможностью задержки реакции, что может привести к увеличению стоимости результатов и снижению производительности системы в целом. Примером может служить работа компьютерной сети. Если система не успела обработать очередной принятый пакет, это приведет к остановке на передающей стороне и повторной посылке (в зависимости от протокола). Данные при этом не теряются, но производительность сети снижается.
Основное отличие систем жёсткого и мягкого реального времени можно охарактеризовать так: система жёсткого реального времени никогда не опоздает с реакцией на событие, система мягкого реального времени не должна опаздывать с реакцией на событие.
Обозначим операционной системой реального времени такую систему, которая может быть использована для построения систем жёсткого реального времени. Это определение выражает отношение к ОСРВ как к объекту, содержащему необходимые инструменты, но также означает, что эти инструменты ещё необходимо правильно использовать.
Большинство программного обеспечения ориентировано на «мягкое» реальное время. Для подобных систем характерно:
Классическим примером задачи, где требуется ОСРВ, является управление роботом, берущим деталь с ленты конвейера. Деталь движется, и робот имеет лишь маленький промежуток времени, когда он может её взять. Если он опоздает, то деталь уже не будет на нужном участке конвейера, и следовательно, работа не будет сделана, несмотря на то, что робот находится в правильном месте. Если он подготовится раньше, то деталь ещё не успеет подъехать, и он заблокирует ей путь.
Таблица сравнения ОСРВ и обычных операционных систем:
ОС реального времени |
ОС общего назначения |
|
Основная задача |
Успеть среагировать на события, происходящие на оборудовании |
Оптимально распределить ресурсы компьютера между пользователями и задачами |
На что ориентирована |
Обработка внешних событий |
Обработка действий пользователя |
Как позиционируется |
Инструмент для создания конкретного аппаратно-программного комплекса реального времени |
Воспринимается пользователем как набор приложений, готовых к использованию |
Кому предназначена |
Квалифицированный разработчик |
Пользователь средней квалификации |
Многие операционные системы общего назначения также поддерживают указанные выше сервисы. Однако ключевым отличием сервисов ядра ОСРВ является детерминированный, основанный на строгом контроле времени, характер их работы. В данном случае под детерминированностью понимается то, что для выполнения одного сервиса операционной системы требуется временной интервал заведомо известной продолжительности. Теоретически это время может быть вычислено по математическим формулам, которые должны быть строго алгебраическими и не должны включать никаких временных параметров случайного характера. Любая случайная величина, определяющая время выполнения задачи в ОСРВ может вызвать нежелательную задержку в работе приложения, тогда следующая задача не уложится в свой квант времени, что послужит причиной для ошибки.[8]
В этом смысле операционные системы общего назначения не являются детерминированными. Их сервисы могут допускать случайные задержки в своей работе, что может привести к замедлению ответной реакции приложения на действия пользователя в заведомо неизвестный момент времени. При проектировании обычных операционных систем разработчики не акцентируют свое внимание на математическом аппарате вычисления времени выполнения конкретной задачи и сервиса. Это не является критичным для подобного рода систем.
В своем развитии ОСРВ строились на основе следующих архитектур.
Архитектуры операционных систем реального времени |
||
|
|
|
Монолитная архитектура |
Уровневая (слоевая) архитектура |
Архитектура «клиентсервер» |
Ядро ОСРВ обеспечивает функционирование промежуточного абстрактного уровня ОС, который скрывает от прикладного ПО специфику технического устройства процессора (нескольких процессоров) и связанного с ним аппаратного обеспечения.
Указанный абстрактный уровень предоставляет для прикладного ПО пять основных категорий сервисов.
В дополнение к сервисам ядра, многие ОСРВ предлагают линейки дополнительных компонентов для организации таких высокоуровневых понятий, как файловая система, сетевое взаимодействие, управление сетью, управление базой данных, графический пользовательский интерфейс и т. д. Хотя многие из этих компонентов намного больше и сложнее, чем само ядро ОСРВ, они, тем не менее, основываются на его сервисах. Каждый из таких компонентов включается во встроенную систему, только если её сервисы необходимы для выполнения встроенного приложения и только для того, чтоб свести расход памяти к минимуму.[8]
Большинство ОСРВ выполняют планирование задач, руководствуясь следующей схемой. Каждой задаче в приложении ставится в соответствие некоторый приоритет. Чем больше приоритет, тем выше должна быть реактивность задачи. Высокая реактивность достигается путем реализации подхода приоритетного вытесняющего планирования (preemptive priority scheduling), суть которого заключается в том, что планировщику разрешается останавливать выполнение любой задачи в произвольный момент времени, если установлено, что другая задача должна быть запущена незамедлительно.
Описанная схема работает по следующему правилу: если две задачи одновременно готовы к запуску, но первая обладает высоким приоритетом, а вторая низким, то планировщик отдаст предпочтение первой. Вторая задача будет запущена только после того, как завершит свою работу первая.
Возможна ситуация, когда задача с низким приоритетом уже запущена, а планировщик получает сообщение, что другая задача с более высоким приоритетом готова к запуску. Причиной этому может послужить какое-либо внешнее воздействие (прерывание от оборудования), как, например, изменение состояния переключателя устройства, управляемого ОСРВ. В такой ситуации планировщик задач поведет себя согласно подходу приоритетного вытесняющего планирования следующим образом. Задаче с низким приоритетом будет позволено выполнить до конца текущую ассемблерную команду (но не команду, описанную в исходнике программы языком высокого уровня), после чего выполнение задачи останавливается. Далее запускается задача с высоким приоритетом. После того, как она прорабатывает, планировщик запускает прерванную первую задачу с ассемблерной команды, следующей за последней выполненой.
Примечание. Ассемблер - это низкоуровневый язык, оперирующий машинными понятиями и концепциями. Не ищите команду вывода строки "hello, world!". Здесь ее нет. Вот краткий перечень действий, которые может выполнить процессор: сложить/вычесть/разделить/умножить/сравнить два числа и в зависимости от полученного результата передать управление на ту или иную ветку, переслать число с одного места в другое, записать число в порт или прочитать его оттуда. Управление периферией осуществляется именно через порты или через специальную область памяти (например, видеопамять). Чтобы вывести символ на терминал, необходимо обратиться к технической документации на видеокарту, а чтобы прочитать сектор с диска - к документации по накопителю. К счастью, эту часть работы берут на себя драйвера и выполнять ее вру
Каждый раз, когда планировщик задач получает сигнал о наступлении некоторого внешнего события (триггер), причина которого может быть как аппаратная, так и программная, он действует по следующему алгоритму.
Эти пять шагов алгоритма также называются переключением задач.
Триггер (триггерная система) класс электронных устройств, обладающих способностью длительно находиться в одном из двух устойчивых состояний и чередовать их под воздействием внешних сигналов. Каждое состояние триггера легко распознаётся по значению выходного напряжения. По характеру действия триггеры относятся к импульсным устройствам их активные элементы (транзисторы, лампы) работают в ключевом режиме, а смена состояний длится очень короткое время.
Отличительной особенностью триггера как функционального устройства является свойство запоминания двоичной информации. Под памятью триггера подразумевают способность оставаться в одном из двух состояний и после прекращения действия переключающего сигнала. Приняв одно из состояний за «1», а другое за «0», можно считать, что триггер хранит (помнит) один разряд числа, записанного в двоичном коде.
В обычных ОСРВ задача может находиться в 3-х возможных состояниях:
Большую часть времени основная масса задач заблокирована. Только одна задача может выполняться на центральном процессоре в текущий момент времени. В примитивных ОСРВ список готовых к исполнению задач, как правило, очень короткий, он может состоять не более чем из двух-трёх наименований.
Основная функция администратора ОСРВ заключается в составлении такого планировщика задач.
Если в списке готовых к выполнению задач последних имеется не больше двух-трех, то предполагается, что все задачи расположены в оптимальном порядке. Если же случаются такие ситуации, что число задач в списке превышает допустимый лимит, то задачи сортируются в порядке приоритета.
В настоящее время для решения задачи эффективного планирования в ОСРВ наиболее интенсивно развиваются два подхода.
При больших загрузках системы EDF более эффективен, нежели RMS.
В связи с проблемой дедлайнов главной проблемой в ОСРВ становится планирование задач (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, поскольку приоритеты становятся динамическими.
Многозадачным системам необходимо распределять доступ к ресурсам. Одновременный доступ двух и более процессов к какой либо области памяти или другим ресурсам представляет определённую угрозу. Существует 3 способа решения этой проблемы
ОСРВ обычно не используют первый способ, потому что пользовательское приложение не может контролировать процессор столько, сколько хочет. Однако, во многих встроенных системах и ОСРВ позволяется запускать приложения в режиме ядра для доступа к системным вызовам и дается контроль над окружением исполнения без вмешательства ОС.
На однопроцессорных системах наилучшим решением является приложение запущенное в режиме ядра, которому позволено блокирование прерываний. Пока прерывание заблокировано приложение использует ресурсы процесса единолично, никакая другая задача или прерывание не может выполняться. Таким образом защищаются все критичные ресурсы. После того как приложение завершит критические действия, оно должно разблокировать прерывания, если таковые имеются. Временное блокирование прерывания позволено только тогда, когда самый долгий промежуток выполнения критической секции меньше, чем допустимое время реакции на прерывание. Обычно этот метод защиты используется только когда длина критического кода не превышает нескольких строк и не содержит циклов. Этот метод идеально подходит для защиты регистров.
Когда длина критического участка больше максимальной или содержит циклы, программист должен использовать механизмы идентичные или имитирующие поведение систем общего назначения, такие как семафоры и посылка сигналов.
Следующим проблемам выделения памяти в ОСРВ уделяется больше внимания, нежели в операционных системах общего назначения.
Во-первых, скорости выделения памяти. Стандартная схема выделения памяти предусматривает сканирование списка неопределенной длины для нахождения свободной области памяти заданного размера, а это неприемлемо, так как в ОСРВ выделение памяти должно происходить за фиксированное время.
Во-вторых, память может стать фрагментированной в случае разделения свободных её участков уже запущенными процессами. Это может привести к остановке программы из-за её неспособности задействовать новый участок памяти. Алгоритм выделения памяти, постепенно увеличивающий фрагментированность памяти, может успешно работать на настольных системах, если те перезагружаются не реже одного раза в месяц, но является неприемлемым для встроенных систем, которые работают годами без перезагрузки.
Простой алгоритм с фиксированной длиной участков памяти очень хорошо работает в несложных встроенных системах.
Также этот алгоритм отлично функционирует и в настольных системах, особенно тогда, когда во время обработки участка памяти одним ядром следующий участок памяти обрабатывается другим ядром. Такие оптимизированные для настольных систем ОСРВ как Unison Operating System или DSPnano RTOS предоставляют указанную возможность.
Как уже упоминалось выше, задержка на переключение контекста потока напрямую зависит от конфигурации памяти, т.е. от модели защиты памяти. Рассмотрим четыре наиболее распространенных в ОСРВ модели защиты памяти.
Фундаментальное требование к памяти в системе реального времени заключается в том, что время доступа к ней должно быть ограничено (или, другими словами, предсказуемо). Прямым следствием становится запрет на использование для процессов реального времени техники вызова страниц по запросу (подкачка с диска). Поэтому системы, обеспечивающие механизм виртуальной памяти, должны уметь блокировать процесс в оперативной памяти, не допуская подкачки. Итак, подкачка недопустима в ОСРВ, потому что непредсказуема.
Если поддерживается страничная организация памяти (paging), соответствующее отображение страниц в физические адреса должно быть частью контекста процесса. Иначе опять появляется непредсказуемость, неприемлемая для ОСРВ.
Для процессов, не являющихся процессами жесткого реального времени, возможно использование механизма динамического распределения памяти, однако при этом ОСРВ должна поддерживать обработку таймаута на запрос памяти, т.е. ограничение на предсказуемое время ожидания.
В обычных ОС при использовании механизма сегментации памяти для борьбы с фрагментацией применяется процедура уплотнения после сборки мусора. Однако такой подход неприменим в среде реального времени, т.к. во время уплотнения перемещаемые задачи не могут выполняться, что ведет к непредсказуемости системы. В этом состоит основная проблема применимости объектно-ориентированного подхода к системам реального времени. До тех пор, пока проблема уплотнения не будет решена, C++ и JAVA останутся не самым лучшим выбором для систем жесткого реального времени.
В системах жесткого реального времени обычно применяется статическое распределение памяти. В системах мягкого реального времени возможно динамическое распределение памяти, без виртуальной памяти и без уплотнения.
При описании управления прерываниями обычно различают две процедуры, а именно:
Обычно ISR реализуются производителем аппаратуры, а драйверы устройств выполняют управление прерываниями с помощью IST. Потоки обработки прерываний действуют как любые другие потоки и используют ту же самую систему приоритетов. Это означает, что проектировщик системы может придать IST более низкий приоритет, чем приоритет потока приложения.
В ОСРВ используются различные службы времени. Операционная система отслеживает текущее время, в определенное время запускает задачи и потоки и приостанавливает их на определенные интервалы. В службах времени ОСРВ используются часы реального времени. Обычно используются высокоточные аппаратные часы. Для отсчета временных интервалов на основе часов реального времени создаются таймеры.
Для каждого процесса и потока определяются часы процессорного времени. На базе этих часов создаются таймеры; которые измеряют перерасход времени процессом или потоком, позволяя динамически выявлять программные ошибки или ошибки вычисления максимально возможного времени выполнения. В высоконадежных, критичных ко времени системах важно выявление ситуаций, при которых задача превышает максимально возможное время своего выполнения, т.к. при этом работа системы может выйти за рамки допустимого времени отклика. Часы времени выполнения позволяют выявить возникновение перерасхода времени и активизировать соответствующие действия по обработке ошибок.
Большинство ОСРВ оперируют относительным временем. Что-то происходит “до” и “после” некоторого другого события. В системе, полностью управляемой событиями, необходим часовой механизм (ticker), т.к. там нет квантования времени (time slicing). Однако, если нужны временные метки для некоторых событий или необходим системный вызов типа “ждать одну секунду”, то нужен тактовый генератор и/или таймер.
Синхронизация в ОСРВ осуществляется с помощью механизма блокирования (или ожидания) до наступления некоторого события. Абсолютное время не используется.
Реализации в ОСРВ других концептуальных абстракций подобны их реализациям в традиционных ОС.
А также другие работы, которые могут Вас заинтересовать | |||
38850. | Эстетическое воспитание подростков на занятиях по художественному текстилю на примере серии работ «Флора» в технике холодный батик | 1.24 MB | |
ИСТОРИКОКУЛЬТУРОЛОГИЧЕСКИЙ АСПЕКТ СТАНОВЛЕНИЯ И РАЗВИТИЯ ХУДОЖЕСТВЕННОЙ РОСПИСИ ТКАНИ И ЕЁ ТРАНСФОРМАЦИЯ В СОВРЕМЕННОМ ТВОРЧЕСТВЕ. История возникновения и развития художественной росписи ткани в странах Азии и Европы10 Исторические аспекты развития художественной росписи ткани России20 1.3 Роль художественной росписи ткани в современном декоративно прикладном искусстве в контексте моды как культурного феномена и ее связи с современным искусством росписи... | |||
38851. | Обучающая подсистема для лабораторного исследования характеристик замкнутых САУ в среде интернет | 4.57 MB | |
В данном дипломном проекте рассматривается обучающая подсистема для лабораторного исследования характеристик замкнутых САУ в среде интернет. В экономической части дается техникоэкономическое обоснование разработки Обучающей подсистемы для лабораторного исследования характеристик замкнутых САУ в среде интернет с помощью частотных критериев устойчивости проводится расчет ее сметной стоимости и стоимости эксплуатации Содержание.1 Описание предметной области по характеристикам замкнутых САУ. | |||
38852. | Фотокаталітичне очищення стічних вод від біогенних елементів | 5.96 MB | |
Представлено та описано технологічну схему очищення стічних вод від біогенних елементів фотокаталітичною технологією за допомогою солей Ti(IV) та Zr(IV). Виконано розрахунок і вибір основного та допоміжного обладнання у відповідності з задоною продуктивністю установки. Надано його характеристику. | |||
38854. | Створення та редагування таблиць у текстовому редакторі Word | 327.5 KB | |
Поняття таблиць Word Таблиці дуже часто зустрічаються в діловій кореспонденції однак існує деяка думка що створювати і редагувати таблиці в текстових процесорах украй складно. Word дозволяє вставляти таблиці з текстовою і графічною інформацією будьякого. Приклад таблиці До того як у Word зявилася можливість створювати таблиці користувачі робили це за допомогою табуляції чи абзацних відступів. Звичайно таблиці можна створювати таким чином але це досить незручно. | |||
38855. | Забезпечення стабільного функціонування ОЕС України в умовах недостатності маневрових потужностей | 4.98 MB | |
Вибір засобів обмеження перенапруг та високочастотних загороджувачів Для захисту обладнання від атмосферних та комутаційних перенапруг встановлюємо розрядники та обмежувачі перенапруг: ЛЕП330 кВ сторона ВН БТ ОПН330У1 сторона НН БТ РВМ15У1 сторона НН АТВП РВРД10У1 Для забезпечення нормальної роботи звязку та приладів РЗА встановлюємо на ЛЕП високочастотні загороджувачі [5]: 330кВ ВЗ125005У1 2.14 Розрахунок грозозахисту ВРУ330 кВ Вихідні дані для розрахунку: висота блискавковідводу: h=40м; розрахункова... | |||
38857. | ФИЗИЧЕСКАЯ РЕАБИЛИТАЦИЯ ДЕТЕЙ С ДЦП С ИСПОЛЬЗОВАНИЕМ ТРЕНАЖЁРА ГРОССА | 521.5 KB | |
3 Методы и методические приемы используемые в комплексной физической реабилитации детей с ДЦП.4 Использование тренажерных устройств в физической реабилитации детей с ДЦП21 Заключение. Развитие двигательной активности детей. | |||