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

 

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=