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

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

Введение

В течение многих лет приложения на базе ОС реального времени

использовались во встроенных системах специального назначения, а с

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

управления ЛА, до бытовых приборов.

Разработка многопроцессорных вычислительных систем (ВС) как правило,

имеет своей целью повышение либо уровня надежности, либо уровня

производительности системы до значений недоступных или труднореализуемых в

традиционных ЭВМ.

В первом случае на передний план встает вопрос о наличии специальных

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

особенностью (и достоинством) которых является отсутствие какого-либо

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

всей системы.

Таким образом, объектом исследования в рамках сетевой отказоустойчивой

технологии становится ОСРВ — управляющее программное обеспечение особого

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

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

производительность, а также требования гарантированного времени отклика,

высокого уровня готовности и наличия средств автомониторинга.

Данная дипломная работа посвящена разработке специализированной

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

ВС с рангом отказоустойчивости N(N-1), что означает способность системы

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

системы за исключением одного. Для полного освещения выбранной темы были

поставлены следующие задачи:

1. Провести анализ существующих операционных систем реального времени,

выделить основные функциональные требования к ним, дать

сравнительную характеристику.

2. Раскрыть концепцию построения ОСРВ с рангом отказоустойчивости N-1,

выделить основные модули операционной системы, функциональные

требования к ним и алгоритмы работы.

3. Раскрыть логику организации отказоустойчивых вычислений на примере

конкретной реализации.

4. Провести анализ надежности отказоустойчивой ВС и дать рекомендации

по организации ВС.

5. Создать программную модель вычислительной системы с распределенной

операционной системой реального времени и отработать на ней

различные режимы работы.

6. Рассмотреть возможность портирования (переноса) ОСРВ на платформу

TMS320c30, рассмотреть специфические проблемы и сложности при

осуществлении портации.

В первой части работы дано краткое описание известных ОСРВ, описаны их

функциональные возможности, структура, их направленность (специфические

особенности). Также приведена сравнительная характеристика и отмечены те

решения, которые можно было бы использовать для разработки собственной

специализированной ОСРВ.

Во второй главе описана концепция построения распределенной ОСРВ, были

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

вычислительной системы, включающие в себя многопроцессорность, обеспечение

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

реального масштаба времени, мобильность и открытость программного

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

примере пяти-узловой полносвязной сети ПЭ в условиях постоянной деградации

системы.

Далее рассмотрена программная модель ВС и операционной системы,

логика работы и взаимосвязь модулей.

В последней главе рассматриваются особенности аппаратной платформы

TMS320c30, вопросы реализации вышеприведенных идей с помощью этой

платформы, дополнение ОС специфическими для данной архитектуры модулями.

Специальная часть

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

ОС общего назначения, особенно многопользовательские, ориентированы на

оптимальное распределение ресурсов компьютера между пользователями и

задачами (системы разделения времени), В операционных системах реального

времени (ОСРВ), подобная задача отходит на второй план - все отступает

перед главной задачей - успеть среагировать на события, происходящие на

объекте.

1 Описание и общие требования к системам реального времени.

Применение операционной системы реального времени всегда связано с

аппаратурой, с объектом, с событиями, происходящими на объекте. Система

реального времени, как аппаратно-программный комплекс, включает в себя

датчики, регистрирующие события на объекте, модули ввода-вывода,

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

этих показаний на компьютере, и, наконец, компьютер с программой,

реагирующей на события, происходящие на объекте. ОСРВ ориентирована на

обработку внешних событий. Именно это приводит к коренным отличиям (по

сравнению с ОС общего назначения) в структуре системы, в функциях ядра, в

построении системы ввода-вывода. ОСРВ может быть похожа по

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

совершенно иначе - об этом речь впереди.

Кроме того, применение ОСРВ всегда конкретно. Если ОС общего

назначения обычно воспринимается пользователями (не разработчиками) как уже

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

конкретного аппаратно - программного комплекса реального времени. И поэтому

наиболее широкий класс пользователей ОСРВ - разработчики комплексов

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

Проектируя и разрабатывая конкретную систему реального времени, программист

всегда знает точно, какие события могут произойти на объекте, знает

критические сроки обслуживания каждого из этих событий.

Назовем системой реального времени (СРВ) аппаратно-программный

комплекс, реагирующий в предсказуемые времена на непредсказуемый поток

внешних событий.

Это определение означает, что:

. Система должна успеть отреагировать на событие, произошедшее на

объекте, в течение времени, критического для этого события. Величина

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

событием, и, естественно, может быть разной, но время реакции системы

должно быть предсказано (вычислено) при создании системы. Отсутствие

реакции в предсказанное время считается ошибкой для систем реального

времени.

. Система должна успевать реагировать на одновременно происходящие

события. Даже если два или больше внешних событий происходят

одновременно, система должна успеть среагировать на каждое из них в

течение интервалов времени, критического для этих событий.

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

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

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

реакции системы ни при каких условиях, так как:

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

. может произойти катастрофа в случае задержки реакции,

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

Примеры систем жесткого реального времени - бортовые системы

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

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

реакции не критична, хотя и может привести к увеличению стоимости

результатов и снижению производительности системы в целом.

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

можно выразить так: система жесткого реального времени никогда не опоздает

с реакцией на событие, система мягкого реального времени - не должна

опаздывать с реакцией на событие.

Тогда операционная система реального времени - это такая ОС,

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

времени. Это определение выражает отношение к ОСРВ как к объекту,

содержащему необходимые инструменты, но также означает, что этими

инструментами еще необходимо правильно воспользоваться.

1.2. Параметры ОСРВ

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

Почти все производители систем реального времени приводят такой

параметр, как время реакции системы на прерывание (interrupt latency).

В самом деле, если главным для системы реального времени является ее

способность вовремя отреагировать на внешние события, то такой параметр,

как время реакции системы является ключевым.

События, происходящие на объекте, регистрируются датчиками, данные с

датчиков передаются в модули ввода-вывода (интерфейсы) системы. Модули

ввода-вывода, получив информацию от датчиков и преобразовав ее, генерируют

запрос на прерывание в управляющем компьютере, подавая ему тем самым сигнал

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

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

Интервал времени - от события на объекте и до выполнения первой

инструкции в программе обработки этого события и является временем реакции

системы на события.

Обычно время реакции систем на прерывание составляет порядка 4-10

мкс.

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

В операционные системы реального времени заложен параллелизм,

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

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

Контекст задачи это набор данных, задающих состояние процессора при

выполнении задачи. Обычно совпадает с набором регистров, доступных для

изменения прикладной задаче.

При переключении задач (процессов) необходимо:

1. корректно остановить работающую задачу;

для этого

а) выполнить инструкции текущей задачи, уже загруженные в процессор,

но еще не выполненные;

б) сохранить в оперативной памяти регистры текущей задачи;

2. найти, подготовить и загрузить затребованную задачу;

3. запустить новую задачу, для этого

а) восстановить из оперативной памяти регистры новой задачи

(сохраненные ранее,

если она до этого уже работала);

б) загрузить в процессор инструкции новой задачи.

Каждая из этих стадий вносит свой вклад в задержку при переключении

контекста. Поскольку любое приложение реального времени должно обеспечить

выдачу результата в заданное время, то эта задержка должна быть мала,

детерминирована и известна. Это число является одной из важнейших

характеристик ОСРВ. Обычно время переключения контекста в ОСРВ составляет

10-20 мкс.

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

Для систем реального времени важным параметром является размер

системы исполнения, а именно суммарный размер минимально необходимого для

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

д.). Хотя, надо признать, что с течением времени значение этого параметра

уменьшается, тем не менее, он остается важным и производители систем

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

модулей системы были невелики.

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

Важным параметром при оценке ОСРВ является набор инструментов,

механизмов реального времени, предоставляемых системой.

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

Базовыми инструментами разработки сценария работы системы являются

система приоритетов процессов (задач) и алгоритмы планирования

(диспетчеризации) ОСРВ.

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

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

понятии непрерывного кванта времени ("time slice"), предоставляемого

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

просматривает очередь активных процессов и принимает решение, кому передать

управление, основываясь на приоритетах процессов (численных значениях, им

присвоенных). Приоритеты могут быть фиксированными или меняться со временем

- это зависит от алгоритмов планирования в данной ОС, но рано или поздно

процессорное время получат все процессы в системе.

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

Основной недостаток - непрерывный квант времени, в течение которого

процессором владеет только один процесс. Планировщики же ОСРВ имеют

возможность сменить процесс до истечения "time slice", если в этом возникла

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

"приоритетный с вытеснением". Мир ОСРВ отличается богатством различных

алгоритмов планирования: динамические, приоритетные, монотонные, адаптивные

и пр., цель же всегда преследуется одна - предоставить инструмент,

позволяющий в нужный момент времени исполнять именно тот процесс, который

необходим.

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

Другой набор механизмов реального времени относится к средствам

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

развитость этих механизмов. К таким механизмам относятся: семафоры,

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

каналы данных (pipes), очереди сообщений. Многие из подобных механизмов

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

особенности - время исполнения системных вызовов почти не зависит от

состояния системы, и в каждой ОСРВ есть по крайней мере один быстрый

механизм передачи данных от процесса к процессу.

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

Такие инструменты, как средства работы с таймерами, необходимы для

систем с жестким временным регламентом, поэтому развитость средств работы с

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

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

. генерировать прерывания по истечении временных интервалов,

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

Здесь описаны только базовые, обязательные механизмы, использующиеся

в ОСРВ. Кроме того, почти в каждой ОСРВ можно найти целый набор

дополнительных, специфических только для нее механизмов, касающийся системы

ввода-вывода, управления прерываниями, работы с памятью. Каждая система

содержит также ряд средств, обеспечивающих ее надежность: встроенные

механизмы контроля целостности кодов, инструменты для работы с таймерами.

4 Классы систем реального времени

Монолитная архитектура

ОСРВ с монолитной архитектурой можно представить в виде (рис. 1.1)

. прикладного уровня: состоит из работающих прикладных процессов;

. системного уровня: состоит из монолитного ядра операционной системы, в

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

ядром (API), собственно ядро системы, интерфейс между ядром и

оборудованием (драйверы устройств).

[pic]

Рис. 1.1. ОСРВ с монолитной архитектурой

Интерфейс в таких системах играет двойную роль:

1. управление взаимодействием прикладных процессов и системы,

2. обеспечение непрерывности выполнения кода системы (т.е. отсутствие

переключения задач во время исполнения кода системы).

Основным преимуществом монолитной архитектуры является ее

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

достигается это, в основном, за счет написания значительных частей системы

на ассемблере.

Недостатки монолитной архитектуры.

1. Системные вызовы, требующие переключения уровней привилегий (от

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

специальный тип исключений. Это сильно увеличивает время их работы.

2. Ядро не может быть прервано пользовательской задачей (non-

preemptable). Это может приводить к тому, что высокоприоритетная задача

может не получить управления из-за работы низкоприоритетной.

3. Сложность переноса на новые архитектуры процессора из-за

значительных ассемблерных вставок.

4. Негибкость и сложность развития: изменение части ядра системы

требует его полной перекомпиляции.

Модульная архитектура (на основе микроядра)

Модульная архитектура появилась, как попытка убрать интерфейс между

приложениями и ядром и облегчить модернизацию системы и перенос ее на новые

процессоры.

Теперь микроядро играет двойную роль(рис 1.2):

1. управление взаимодействием частей системы (например, менеджеров

процессов и файлов),

1. обеспечение непрерывности выполнения кода системы (т.е. отсутствие

переключения задач во время исполнения микроядра).

[pic]

Рис. 1.2. ОСРВ на основе микроядра

Недостатки модульной архитектуры фактически те же, что и у

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

Системный интерфейс по-прежнему не допускает переключения задач во время

работы микроядра, только сократилось время пребывания в этом состоянии,

проблемы с переносимостью микроядра уменьшились (в связи с сокращением его

Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10