Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Модуль2.docx
Скачиваний:
181
Добавлен:
04.06.2015
Размер:
973.92 Кб
Скачать

12.Специфика и свойства осрв. Технические свойства осрв.

Специфика и свойства ОСРВ.

Главные черты СРВ могут быть определены как комбинация следующих двух определений:

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

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

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

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

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

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

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

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

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

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

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

Отличия ОСВР от ОС:

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

Применение ОСРВ всегда связано с аппаратурой, объектом, событиями, происходящими на объекте. Это приводит к коренным отличиям в структуре ОСРВ по сравнению с обычными ОС. Главное отличие заключается в блоке ввода-вывода.

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

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

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

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

стоимость опоздания может оказаться бесконечно велика.

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

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

Пример - работа сети. Если система не успела обработать очередной принятый пакет, это приведет к таймауту на передающей стороне и повторной посылке (в зависимости от протокола, конечно). Данные при этом не теряются, но производительность сети снижается.

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

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

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

Свойства операционных систем реального времени. Параметры операционных системах реального времени.

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

Системы исполнения и системы разработки операционных системах реального времени

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

Большинство современных ведущих операционных систем реального времени поддерживают целый спектр аппаратных архитектур, на которых работают системы исполнения (Intel, Motorola, RISC,MIPS, PowerPC, и другие). Это объясняется тем, что набор аппаратных средств - часть комплекса реального времени и аппаратура должна быть также адекватна решаемой задаче, поэтому ведущие операционные системы реального времени перекрывают целый ряд наиболее популярных архитектур, чтобы удовлетворить самым разным требованиям по части аппаратуры. Система исполнения операционных системах реального времени и компьютер, на котором она исполняется называют "целевой" (target) системой. Система разработки - набор средств, обеспечивающих создание и отладку приложения реального времени.

Системы разработки (компиляторы, отладчики и всевозможные tools) работают, как правило, в популярных и распространенных ОС, таких, как UNIX и Windows. Кроме того, многие операционные системы реального времени имеют и так называемые резидентные средства разработки, исполняющиеся в среде самой операционной системы реального времени - особенно это относится к операционным системам реального времени класса "ядра" (см. ниже).

Заметим, что функционально средства разработки операционных систем реального времени отличаются от привычных систем разработки

Время реакции системы

Почти все производители систем реального времени приводят такой параметр, как время реакции системы на прерывание (interrupt latency).

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

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

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

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

Время переключения контекста

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

Размеры системы

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

Примеры: размер ядра операционной системы реального времени OS-9 на микропроцессорах МС68xxx - 22 KB, VxWorks - 16 KB.

Возможность исполнения системы из ПЗУ (ROM)

Это свойство операционных систем реального времени - одно из базовых. Оно позволяет создавать компактные встроенные СРВ повышенной надёжности, с ограниченным энергопотреблением, без внешних накопителей.

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

Механизмы реального времени

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

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

Базовыми инструментами разработки сценария работы системы являются система приоритетов процессов (задач) и алгоритмы планирования (диспетчеризации) операционных системах реального времени.

Алгоритмы круговой диспетчеризации неприменимы в чистом виде в операционных системах реального времени. Основной недостаток - непрерывный квант времени, в течение которого процессором владеет только один процесс. Планировщики же операционных систем реального времени имеют возможность сменить процесс до истечения "time slice", если в этом возникла необходимость. Один из возможных алгоритмов планирования при этом "приоритетный с вытеснением". Мир операционных систем реального времени отличается богатством различных алгоритмов планирования: динамические, приоритетные, монотонные, адаптивные и пр., цель же всегда преследуется одна - предоставить инструмент, позволяющий в нужный момент времени исполнять именно тот процесс, который необходим.

Механизмы межзадачного взаимодействия

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

Средства для работы с таймерами

Такие инструменты, как средства работы с таймерами, необходимы для систем с жестким временным регламентом, поэтому развитость средств работы с таймерами - необходимый атрибут операционных систем реального времени. Эти средства, как правило, позволяют:1. измерять и задавать различные промежутки времени (от 1 мкс и выше), 2.генерировать прерывания по истечении временных интервалов, 3.создавать разовые и циклические будильники

Время реакции системы на событие – интервал времени от момента возникновения события на объекте до момента выполн первой команды в программе – обработчике этого события. Планировщик СРВ д уметь вычислять этот интервал.

Включает две компоненты:

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

Блокировка прерываний. Это время в СРВ нужно оценивать в наихудшей ситуации для СРВ (когда происходит какой-то процесс, вызванный прерыванием и в это время происходит другое прерывание, то необходимо блокировать)

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

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

Возможность исполнения СРВ из ПЗУ – позволяет создавать компактные встроенные СРВ высокой надежности и с ограниченным энергопотреблением, для них не нужны внешние накопители. БАЗОВОЕ СВОЙСТВО.

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

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

Время, которое система затрачивает на передачу управления от процесса к процессу (от задачи к задаче, от нити к нити), то есть время переключения контекста.

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

Возможность исполнения системы из ПЗУ - это свойство операционных систем реального времени - одно из базовых. Оно позволяет создавать компактные встроенные СРВ повышенной надёжности, с ограниченным энергопотреблением, без внешних накопителей.

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

Алгоритмы круговой диспетчеризации неприменимы в чистом виде в операционных системах реального времени. Основной недостаток - непрерывный квант времени, в течение которого процессором владеет только один процесс. Планировщики же операционных систем реального времени имеют возможность сменить процесс до истечения "timeslice", если в этом возникла необходимость. Один из возможных алгоритмов планирования при этом "приоритетный с вытеснением". Мир операционных систем реального времени отличается богатством различных алгоритмов планирования: динамические, приоритетные, монотонные, адаптивные и пр., цель же всегда преследуется одна - предоставить инструмент, позволяющий в нужный момент времени исполнять именно тот процесс, который необходим. Время реакции системы на событие – интервал времени от события на объекте и до выполнения первой инструкции в программе обработки этого события. В современных ОСРВ – от 3 мкс до 10 мкс.

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

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

ОСРВ являются многозадачными (многопроцессными, многонитиевыми).

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

Размер системы исполнения – суммарный размер минимально необходимого для работы приложения реального времени системного набора (ядро, системные модули, драйверы и т.д.). Примеры: размер ядра ОСРВ OS-9 на микропроцессорах МС68xxx составляет 22 KB, VxWorks – 16 KB.

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