Контрольная работа по "Информатике". 288

1. Планирование периодических процессов

Внешние события, на которые  СРВ должна реагировать, разделяют  на периодические(возникающие через регулярные промежутки времени) и непериодические (возникающие непредсказуемо). При нескольких обрабатываемых потоков событий в зависимости от времени, затрачиваемого на обработку каждого из событий, может оказаться, что система не в состоянии своевременно обработать все события. Если в систему поступает mпериодических событий, событие с номером i поступает с периодом P_i и на его обработку уходит C_i секунд работы процессора, все потоки могут быть своевременно обработаны только при выполнении условия 
 
. 
 
СРВ, удовлетворяющая этому условию, называется поддающейся планированию(планируемой). Соотношение   является просто частью процессорного времени, используемого процессом i, а сама сумма – это коэффициент использования (коэффициент загруженности) процессора, который не может быть больше 1. 
 
Алгоритмы планирования заданий могут быть разделены на статические и динамические. Статические алгоритмы определяют приемлемый план выполнения заданий по их априорным характеристикам, динамический алгоритм модифицирует план во время исполнения заданий. Издержки на статическое планирование низки, но оно крайне нечувствительно и требует полной предсказуемости той СРВ, на которой оно установлено. Динамическое планирование связано с большими издержками, но способно адаптироваться к меняющемуся окружению.  

2. Алгоритм RMS

Классическим примером статического алгоритма планирования реального времени для прерываемых  периодических процессов является алгоритм RMS (Rate Monotonic Scheduling – планирование с приоритетом, пропорциональным частоте). Этот алгоритм может использоваться для процессов, удовлетворяющих следующим условиям: 

1.  
   Каждый периодический процесс должен быть завершен за время его периода.
2.  
   Ни один процесс не должен зависеть от любого другого процесса.
3.  
   Каждому процессу требуется одинаковое процессорное время на каждом интервале.
4.  
   У непериодических процессов нет жестких сроков.
5.  
   Прерывание процесса происходит мгновенно, без накладных расходов.

 

 

3. Как работает алгоритм RMS. Когда он может быть использован?

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

4. Алгоритм EDF.

Другим популярным алгоритмом планирования является алгоритм EDF (Earliest Deadline First – процесс с ближайшим сроком завершения в первую очередь). Алгоритм EDF представляет собой динамический алгоритм, не требующий от процессов периодичности. Он не требует и постоянства временных интервалов использования процессора. Когда процессу требуется процессорное время, он объявляет о своем присутствии и о сроке выполнения задания. Планировщик хранит список процессов, сортированный по срокам выполнения заданий. Алгоритм запускает первый процесс в списке, у которого самый близкий по времени срок выполнения. Когда новый процесс переходит в состояние готовности, система сравнивает его срок выполнения со сроком выполнения текущего процесса. Если у нового процесса график более жесткий, он прерывает работу текущего процесса.

 

 

5. Как работает алгоритм EDF. Когда может быть использован алгоритм EDF

В начале все процессы находятся в состоянии готовности они запускаются в порядке своих крайних сроков. Процесс А должен быть выполнен 30, В-40, С-50 мс. Таким образом процесс А запускается первым вновь до момента времени 90 выбор алгоритма EDF не отличим от RMS в момент времени 90 мс процесс А переходит в состояние готовности с тем же крайним сроком выполнения 120, что и у процесса В. Планировщик имеет право выбрать любой из процессов однако с прерыванием процесса В будут связаны накладные расходы поэтому планировщик дает возможность отработать этому процессу.

В момент времени 30 возникает  спор между процессами А и С, поскольку  срок выполнения С=50, а А=60 планировщик  выбирает процесс С. В момент времени 90 процесс А переходит в состояние  готовности в 4-ый раз предельный срок процесса А такой же, что и у текущего процесса, поэтому у планировщика появляется выбор прервать работу процесса В или нет. Поскольку необходимости прерывать процесс В нет, то он продолжает свою работу. В отличие от RMS EDF работает с любым набором процессов для которых возможно планирование.

 

6. Определение систем реального времени и системы жесткого и мягкого реального времени.

Операционные системы  реального времени иногда делят  на два типа — системы жесткого реального времени и системы мягкого реального времени.^[5]

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

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

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

• потере актуальности результатов
• большим финансовым потерям
• авариям и катастрофам

Если не выполняется  обработка критических ситуаций либо она происходит недостаточно быстро, система жёсткого реального времени  прерывает операцию и блокирует  её, чтобы не пострадала надёжность и готовность остальной части  системы. Примерами систем жёсткого реального времени могут быть — бортовые системы управления (на самолёте, космическом аппарате, корабле, и пр.), системы аварийной защиты, регистраторы аварийных событий.^[6]

Системы мягкого реального времени характеризуются возможностью задержки реакции, что может привести к увеличению стоимости результатов и снижению производительности системы в целом. Примером может служить работа компьютерной сети.^[7] Если система не успела обработать очередной принятый пакет, это приведет к остановке на передающей стороне и повторной посылке (в зависимости от протокола). Данные при этом не теряются, но производительность сети снижается.

Основное отличие систем жёсткого и мягкого реального времени  можно охарактеризовать так: система  жёсткого реального времени никогда  не опоздает с реакцией на событие, система мягкого реального времени — не должна опаздывать с реакцией на событие.^[7]

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

Большинство программного обеспечения ориентировано на «мягкое» реальное время. Для подобных систем характерно:

• гарантированное время реакции на внешние события (прерывания от оборудования);
• жёсткая подсистема планирования процессов (высокоприоритетные задачи не должны вытесняться низкоприоритетными, за некоторыми исключениями);
• повышенные требования к времени реакции на внешние события или реактивности (задержка вызова обработчика прерывания не более десятков микросекунд, задержка при переключении задач не более сотен микросекунд)

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

 

7. Основные отличия традиционных ОС от ОС РВ

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

8. Применение ОС реального времени всегда связан с аппаратурой, с объектом, событиями происходящими на объекте. Система реального времени как аппаратно-программный комплекс включает в себя
1. датчики, регистрирующие события на объекте
2. модули ввода-вывода, преобразующие показатели датчиков в цифровой вид пригодный для обработки этих показателей, а также
3. компьютера с программой, реагирующей на события на объекте.
9. Применение ОС реального времени всегда конкретно, если ОС общего назначения обычно воспринимается пользователями как уже готовый набор приложений, то ОС реального времени служит только инструментом для создания конкретного аппаратно-программного комплекса реального времени.

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

10. Четкое разграничение систем разработки и систем исполнения:

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

2. Системы разработки – это набор средств обеспечивающих отладку и создание систем реального времени.

 

11. Характеристики ОС реального времени

ОС реального  времени должна обладать определенными свойствами:

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

1. События, происходящие на объекте регистрируются датчиками
2. Данные с датчиков передаются в модули ввода-вывода системы

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

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

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

1. Обычные компьютеры
2. Промышленные компьютеры

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

3. Встраиваемые системы

Устанавливаются внутрь оборудования, которым они управляют.

 

12. Свойства ОС реального времени

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

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

2. Возможность исполнения системы из ПЗУ

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

3. Наличие необходимых драйверов устройств

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

4. Поддержка процессоров различной архитектуры

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

5. Специальный кроссплатформенный инструментарий разработчика

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

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

Предсказуемой систему реального времени делают:

1. Система приоритетов процессов и алгоритмы диспетчеризации

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

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

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

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

Они необходимы для систем с жестким временным регламентом и как правило позволяют:

1. Измерять и задавать различные промежутки времени от 1 микросекунды и выше
2. Генерировать прерывание по истечению временных интервалов

Создавать разовые  и циклические будильники

 

13. Что делает СРВ предсказуемой?

Классификация приложений систем реального времени

Основной параметр –  предсказуемость.

Две парадигмы приложений для предсказуемости систем:

1. Архитектура приложения, работающего по событию. (ET – Event Type).
2. Архитектура приложения, функционирующего по времени. (TT – Time Type).

ET – подход

Любая деятельность системы  начинается в ответ на возникающее специфическое событие. Вид события определяется самой системой. Предсказуемость достигается следующими способами:

1. Использование стратегии  оценки для каждой прикладной  задачи (оценивается потребность  данной задачи в текущий момент  времени). Проверяется несколькими способами:

а) Проверяется загруженность  узла.

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

2. Оценка потребности  ресурсов для данной задачи.

3. Оценка готовности  ресурсов для удовлетворения  потребностей и задач.

Достоинства: управляемость  со стороны системы, независимость  от времени (количества тактов).

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

ТТ – подход

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

Достоинства:

1. На всех узлах задачи могут исполняться по синхронизированному времени.
2. Таблица задач является фиксированной, для неё можно провести моделирование на возможность функционирования в режиме РВ.

Недостатки: слабая управляемость  процесса исполнения задач. Не существует возможности управления последовательностью  задач в процессе функционирования системы.

 

14. Функции ядра ОСРВ

Ядро может  обеспечивать сервис 5 типов:

1. Синхронизация ресурсов

Этот метод требует  ограничить доступ к общим ресурсам. Наиболее распространенный тип синхронизации - двоичный симофор.

2. Межзадачный обмен

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

3. Разделение данных

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

4. Обработка запросов внешних устройств

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

5. Обработка особых ситуации

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

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

Процесс может  находиться в одном из следующих состоянии:

1. Остановлен

Процесс остановлен и  не использует процессор, например в  таком состоянии процесс находится  сразу после создания.

2. Терминирован

Процесс терминирован и  не использует процессор. Например, процесс  закончился, но еще не удален ОС

3. Ждет

Процесс ждет некоторого события.

4. Готов

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

5. Выполняется

Процесс выполняется  и используется процессор. В ОСРВ это означает, что этот процесс  наиболее приоритетный из всех процессов, находившихся в состоянии "готов".

 

 

 

15. Учет особенностей жестких СРВ.

 

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

 

четкое разделение типов  действий/объектов, которые находятся  в жестких системах реального  времени (т.е. циклические и еденичные  действия).

точное определение требований приложения по распределению времени для каждого объекта.

определение относительной  важности каждого объекта для  успешного функционирования приложения.

точное определение  и использование объектов контроля ресурсов.

переход к наиболее подходящей для планировки и распределения времени программной архитектуре.

 

 

 

 

 

 

 

 

 

 

 

16.  Жизненный цикл жестких СРВ

Наш подход заключается  в разделении архитектурного плана  на две фазы:

• логическая архитектура
• физическая архитектура

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

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

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

17.  ОСРВ (монолитная, на основе микроядра, объектно-ориентированная).

В своем развитии ОСРВ строились на основе следующих архитектур.

• Монолитная архитектура. ОС определяется как набор модулей, взаимодействующих между собой внутри ядра системы и предоставляющих прикладному ПО входные интерфейсы для обращений к аппаратуре. Основной недостаток этого принципа построения ОС заключается в плохой предсказуемости её поведения, вызванной сложным взаимодействием модулей между собой.
• Уровневая (слоевая) архитектура. Прикладное ПО имеет возможность получить доступ к аппаратуре не только через ядро системы и её сервисы, но и напрямую. По сравнению с монолитной такая архитектура обеспечивает значительно большую степень предсказуемости реакций системы, а также позв<span class="dash041e_0431_044b_0447_043d_044b_0439__Char" style=