Реферат по теме выпускной работы

Содержание

• Введение
• 1. Цели и задачи разработки и исследования
• 2. Основные положения о системах реального времени
  • 2.1 Основные понятия
  • 2.2 Структура систем реального времени
  • 2.3 Процессы, потоки, задачи
  • 2.4 Механизмы реального времени
  • 2.5 Часы и таймеры
• 3. Особенности отладки приложений в системах реального времени
• Выводы
• Список литературы

Введение

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

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

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

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

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

1. Цели и задачи разработки и исследования

Целью магистерской работы является разработка удобного инструментария для отладки алгоритмов работы диспетчера и планировщика задач для операционных систем реального времени. Для достижения цели будет взята платформа Qt, язык C++ и QML, что позволит не только предоставить интуитивно понятный интерфейс и быструю отзывчивость приложения, но и даст возможность запускать приложения на множестве операционных систем, поддерживаемых платформой Qt. Приложение разрабатывается по модульной парадигме, что позволит без особых проблема заменить любую его часть.

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

2. Основные положения о системах реального времени

2.1 Основные понятия

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

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

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

2. Стандарт POSIX 1003.1 определяет СРВ следующим образом: Реальное время в операционных системах — это способность операционной системы обеспечить требуемый уровень сервиса в заданный промежуток времени.

3. Иногда системами реального времени называется системы постоянной готовности (on-line системы), или интерактивные системы с достаточным временем реакции. Обычно это делают по маркетинговым соображениям. Действительно, если интерактивную программу называют работающей в реальном времени, то это просто означает, что она успевает обработать запросы от человека, для которого задержка в сотни миллисекунд даже незаметна.

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

5. Во многих сферах приложения СРВ вводят свои понятия реального времени. Например, процесс цифровой обработки сигнала называют идущим в реальном времени, если анализ (при вводе) и/или генерация (при выводе) данных может быть проведен за то же время, что и анализ и/или генерация тех же данных без цифровой обработки сигнала. Например, если при обработке аудио данных требуется 2.01 секунд для анализа 2.00 секунд звука, то это не процесс реального времени. Если же требуется 1.99 секунд, то это процесс реального времени.

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

1) Система должна успеть отреагировать на событие, произошедшее на объекте, в течение времени, критического для этого события (meet deadline). Величина критического времени для каждого события определяется объектом и самим событием, и, естественно, может быть разной, но время реакции системы должно быть предсказано (вычислено) при создании системы. Отсутствие реакции в предсказанное время считается ошибкой для систем реального времени.

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

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

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

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

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

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

2.2 Структура систем реального времени

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

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

Управляемая подсистема представлена задачами, которые используют оборудование, управляемое подсистемой контроля. Эта последняя подсистема может быть построена из очень большого количества процессоров, управляющими такими местными ресурсами, как память и устройства хранения, и доступ к локальной сети в реальном масштабе времени. Эти процессоры и ресурсы управляются системой программного обеспечения, которую и называют операционной системой реального масштаба времени (RTOS — real time operating system) [2].

2.3 Процессы, потоки, задачи

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

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

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

Преимущества потоков

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

Недостатки потоков

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

Как правило, вся важная, с точки зрения операционной системы, информация о задаче хранится в унифицированной структуре данных — управляющем блоке (Task Control Block, TCB). В блоке хранятся такие параметры, как имя и номер задачи, верхняя и нижня границы стека, ссылка на очередь сообщений, статус задачи, приоритет и т.п.

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

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

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

1. Активная задача — это задача, выполняемая системой в текущей момент времени.
2. Готовая задача — это задача, готовая к выполнению и ожидающая у планировщика своей очереди.
3. Блокированная задача — это задача, выполнение которой приостановлено до наступления определенных событий. Такими событиями могут быть освобождение необходимого задаче ресурса, поступление ожидаемого сообщения, завершение интервала ожидания и т.п.

Пустая задача (Idle Task) — это задача, запускаемая самой операционной системой в момент инициализации и выполняемая только тогда, когда в системе нет других готовых для выполнения задач. Пустая задача запускается с самым низким приоритетом и, как правило, представляет собой бесконечный цикл «ничего не делать». Наличие пустой задачи предоставляет операционной системе удобный механизм отработки ситуаций, когда нет ни одной готовой к выполнению задачи.

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

Реентерабельность (повторная входимость) означает возможность без негативных последствий временно прервать выполнение какой-либо функци или подпрограммы, а затем вызвать эту функцию или подпрограмму снова. Частным проявлением реентерабельности является рекурсия, когда тело подпрограммы содержит вызов самой себя. Классическим примером нереентерабельной системы является DOS, а типичной причиной нереентерабельности служит использование глобальных переменных [3].

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

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

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

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

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

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

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

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

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

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

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

2.5 Часы и таймеры

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

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

Большинство ОСРВ оперируют относительным временем. Что-то происходит до и после некоторого другого события. В системе, полностью управляемой событиями, необходим часовой механизм (ticker), т.к. там нет квантования времени (time slicing). Однако, если нужны временные метки для некоторых событий или необходим системный вызов типа ждать одну секунду, то нужен тактовый генератор и/или таймер.

Синхронизация в ОСРВ осуществляется с помощью механизма блокирования (или ожидания) до наступления некоторого события. Абсолютное время не используется [4].

3. Особенности отладки приложений в системах реального времени

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

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

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

Второй способ — удаленная отладка (кросс-отладка). Кросс-отладка позволяет использовать ресурсы инструментальной системы при изучении поведения некоторого процесса в целевой системе.

Эффективность удаленной отладки зависит от типа связи инструментальной и целевой машин, а также от поддержки средств отладки со стороны целевой архитектуры.

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

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

Под мониторингом понимается сбор данных о задаче (значения регистров, переменных, и т.д.) или о системе в целом (стадии выполнения задач, происходящие события, и т.д.).

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

В процессе мониторинга отладчик практически не вмешивается в работу системы, обеспечивая нормальное ее функцирование, но вместе с тем не имеет возможности влиять на ход выполнения отлаживаемого приложения [5].

Выводы

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

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

Список литературы

1. Братуха М.А., Шевченко О.Г. Исследование точности отсчёта временных интервалов в системе Windows
2. Системы реального времени: учебно пособие — СПб.: Владикавказ, 2013. — 65 с.
3. Сорокин С. Системы реального времени // Современные технологии автоматизации. 1997. № 2.
4. Бурдонов И.Б., Косачев А.С., Пономаренко В.Н. Операционные системы реального времени [электронный ресурс]. — Режим доступа: http://citforum.ru/operating_systems/rtos/, свободный.
5. Костюхин К.А. Отладка систем реального времени [электронный ресурс]. — Режим доступа: http://citforum.ru/programming/digest/rtsdebug.shtml, свободный.
6. Операционная система реального времени / Материал из Википедии — свободной энциклопедии [электронный ресурс]. — Режим доступа: https://ru.wikipedia.org/wiki/Операционная_система_реального_времени, свободный.
7. ОСи реального времени / журнал Хакер [электронный ресурс]. — Режим доступа: http://www.xakep.ru/post/17912/, свободный.
8. Операционные системы реального времени (обзор) А.А. Блискавицкий, С.В. Кабаев, АО "РТСофт", Москва [электронный ресурс]. — Режим доступа: http://www.mka.ru/?p=40774, свободный.