Особенности систем реального времени

Московский  Авиационный Институт

(Государственный  Технический Университет)

Факультет №3

Системы управления, информатика  и электроэнергетика

     Кафедра №302 

Автоматизированные системы обработки информации и управления

Реферат

на  тему: «Особенности систем реального времени» 
 
 
 
 
 
 

Выполнили

студент группы № 03-522:

Бердник А.Г.

Матвеев К.В. 

Проверил:

Секретарев  В. Е. 
 
 

Москва, 2011 г. 

Содержание  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Особенности архитектуры систем реального времени

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

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

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

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

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

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

Операционная  система реального  времени

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

Системы жёсткого и мягкого  реального времени

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

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

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

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

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

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

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

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

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

Архитектуры ОСРВ

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

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

 

 

• Уровневая (слоевая) архитектура. Прикладное ПО имеет возможность получить доступ к аппаратуре не только через ядро системы и её сервисы, но и напрямую. По сравнению с монолитной такая архитектура обеспечивает значительно большую степень предсказуемости реакций системы, а также позволяет осуществлять быстрый доступ прикладных приложений к аппаратуре. Главным недостатком таких систем является отсутствие многозадачности.

 

 
 

• Архитектура «клиент-сервер». Основной её принцип заключается в вынесении сервисов ОС в виде серверов на уровень пользователя и выполнении микроядром функций диспетчера сообщений между клиентскими пользовательскими программами и серверами — системными сервисами. Преимущества такой архитектуры:

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

2. Улучшенная масштабируемость, поскольку ненужные сервисы могут быть исключены из системы без ущерба к её работоспособности;
3. Повышенная отказоустойчивость, так как «зависший» сервис может быть перезапущен без перезагрузки системы.

 

 

Отличия от операционных систем общего назначения

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

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

Выделение памяти

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

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

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

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

     Также этот алгоритм отлично функционирует  и в настольных системах, особенно тогда, когда во время обработки участка памяти одним ядром следующий участок памяти обрабатывается другим ядром. Такие оптимизированные для настольных систем ОСРВ, как Unison Operating System или DSPnano RTOS, предоставляют указанную возможность. 

Отладка систем реального времени

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

Существующие СРВ  являются многозадачными. Многозадачность  реализуется через многопроцессность и многопоточность.

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