· средства межзадачных взаимодействий как в стандарте POSIX (семафоры, разделяемая память, сокеты, сигналы, каналы, мьютексы, условные переменные), так и в терминах Unix SystemV (очереди сообщений, семафоры, разделяемая память);

· поддержка таймеров реального времени и часов POSIX;

· конфигурирование квантов времени для различных уровней приоритетов и для разрешения значения единицы (tick) таймера;

· выполнение задач в защищенном режиме, полная поддержка MMU (Memory Management Unit).

1.4.2. OS-9/Hawk фирмы Microware Systems.

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

1.4.2.1. Основные свойства OS-9/Hawk.

· Переносимая версия OS-9 позволяет применять в проекте наиболее подходящие микропроцессорные устройства (Motorola ColdFire; Motorola M-CORE; Intel Pentium; Intel StrongARM; PowerPC; ARM; Hitachi SuperH; MIPS; MicroSPARC).

· Система ввода-вывода ОС поддерживает различные форматы устройств массовой памяти и основных интерфейсов периферийных устройств: Raw, MS-DOS, True FFS, CardSoft PCMCIA, USB, IrDA.

· В среде OS-9 пользователь может выбирать несколько программных коммуникационных платформ: mwSoftStax (Microware), Harris & Jeffries, Trillium, - что ранее было исключительно прерогативой специализированных ОС.

· В инструментальный пакет Hawk встроена библиотека Tools.h из библиотеки Rogue Wave C++ Classes Lib.

· Hawk - интегрированная кросс-среда разработки приложений для OS-9 - функционирует на платформе MS Windows NT.

· Hawk является открытой средой и предоставляет сторонним разработчикам инструментальных средств более сотни API, позволяющих включать в рамках Hawk Partners Program в состав среды Hawk продукты известных фирм разработчиков инструментального ПО.

· Средство верификации программного обеспечения CodeTEST (Applied Microsystems) встроено в Hawk и представляет собой удобный и эффективный инструментарий трассировки встраиваемого ПО и контроля его характеристик, а также хода выполнения тестов и распределения памяти.

1.4.2.2. Поддержка приложений жёсткого реального времени.

· масштабируемое, полностью вытесняемое ядро ОС;

· поддерживает функционирование до 65535 процессов;

· предоставляет 65535 уровней приоритета;

· обеспечивает работу до 255 пользователей;

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

· характеристики производительности: 5.6 мкс Interrupt Latence Time, 14 мкс для времени переключения контекста процесса (MC68040, 30MHz).

1.4.3. VxWorks фирмы Wind River Systems.

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

1.4.3.1. Основные свойства VxWorks.

· Поддерживаемые целевые архитектуры (targets): Motorola 680х0 и CPU32, PowerPC; Intel 386/486/Pentium, Intel 960; Sparc, Mips R3000/4000; AMD 29K, Motorola 88110; HP PA-RISC; Hitachi SH7600; DEC Alpha.

· Поддерживаемые инструментальные платформы (hosts): Sun SPARCstation (SunOS и Solaris); HP 9000/400,700 (HP-UX); IBM RS6000 (AIX); Silicon Graphics (IRIX); DEC Alpha (OSF/1); PC (Windows).

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

· В последней версии VxWorks 5.2 реализованы совместимые с расширениями POSIX для приложений реального времени (POSIX Real-Time Extensions 1003.1b) функции асинхронного ввода-вывода, счётные семафоры, очереди сообщений, сигналы, управление памятью (блокировка страниц), управление диспетчеризацией, часы и таймеры.

· Стандартным языком программирования в инструментальном комплексе VxWorks является язык С. Система программирования на языке C++ не входит в стандартную конфигурацию инструментального комплекса VxWorks и поставляется как дополнительный продукт. Система программирования на языке Ada для VxWorks поставляется почти всеми Ada-производителями.

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

1.4.3.2. Поддержка приложений жёсткого реального времени.

· Построена по технологии микроядра.

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

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

1.4.4. QNX4 фирмы ОРАКУЛ.

QNX4 -- многозадачная многопользовательская операционная система жесткого реального времени (ОСРВ) с архитектурой на основе микроядра и поддержкой ряда стандартов семейства POSIX.

1.4.4.1. Основные свойства QNX4.

· Состоит из микроядра и набора необязательных модулей.

· Предоставляет сервисы стандарта POSIX.1 и его расширения для систем реального времени POSIX.1b (POSIX.4).

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

· Предоставляемое QNX4 окружение защищенного режима дает возможность легко и безопасно тестировать свои новые модули расширения.

· Возможности высокоскоростной трассировки диагностических событий.

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

1.4.4.2. Поддержка приложений жёсткого реального времени.

· Являясь истинно микроядерной ОС, QNX4 строится вокруг компактного высоконадежного «стержня» - имеет микроядро размером всего 10 Кбайт.

· Микроядро QNX4 обладает достаточно малыми размерами для встраивания в ПЗУ.

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

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

1.4.5. Вывод.

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

1.5. Методология разработки программного обеспечения.

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

1.5.1. История развития.

Объектно-ориентированные методологии разработки программного обеспечения (первое направление) стали интенсивно развиваться с конца 80-х годов. В 1997 г. OMG (Object Management Group) приняла UML, появившийся в результате слияния ряда известных методологий, в качестве стандарта языка объектно-ориентированного моделирования. Еще одним объектно-ориентированным подходом является методология ROOM, созданная для разработки систем реального времени. Одновременно в течение последних 20 лет международным комитетом ITU развиваются стандарты для разработки телекоммуникационных систем (второе направление): SDL, MSC и т.д. Кроме того, с 70-х годов развиваются структурные методологии разработки программного обеспечения (третье направление): SADT, IDEF-стандарты, метод Йордана и т.д. В настоящее время эти методологии прочно закрепились в области разработки информационных систем. Они являются эффективным средством анализа систем в целом и успешно применяются.

В данной работе описывается объектно-ориентированная методология Real. Методология Real основывается, главным образом, на UML, SDL, ROOM и отражает перечисленные интеграционные тенденции. Помимо стандартных для объектно-ориентированного подхода черт в Real добавлены дополнительные возможности, направленные на две специальные области программного обеспечения: для информационных систем и для систем реального времени.

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

1.5.2. Разработка программного обеспечения систем реального времени

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

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

В терминах Real основной структурной единицей системы реального времени является объект. Объекты взаимодействуют друг с другом через интерфейсы. Под взаимодействием понимается посылка сообщений, вызов методов и обращение к атрибутам интерфейса. Поскольку в последнее время все большее число систем реального времени становятся распределенными и сетевыми, понятие интерфейса приобретает особую важность. Раньше ситуация была иной, примером чего служат ранние версии языка SDL, в которых интерфейсы отсутствовали. Интерфейсы Real сильно отличаются от портов (gate) SDL (составом, способом связи с классами) и интерфейсов UML (составом, способом связи с классами, способом изображения), а также интерфейсов в ROOM (составом и способом изображения).

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

Компонента программного обеспечения, определенная в виде класса с портами и интерфейсами, может иметь конечно-автоматное поведение, описываемое в терминах поведенческой модели Real. Поведенческая модель, в свою очередь, представляется двумя альтернативными нотациями: первая основана на варианте STD, представленном в ROOM, вторая -- на расширенном конечном автомате SDL. С помощью STD-нотации удобно определять поведение компонент системы на ранних этапах разработки: множество мелких деталей можно временно убрать из поля зрения. В то же время на SDL-диаграммах можно наглядно изобразить мельчайшие подробности алгоритмов.

Эта возможность становится полезной на поздних этапах проектирования. При этом информацию, изображенную на STD-диаграммах, можно ”загрузить” на SDL-диаграммы, таким образом, результаты ранних этапов при переходе к более формальной спецификации не будут потеряны. В рамках Real, STD и SDL нотации предназначены для описания единой поведенческой модели, так что всегда возможно и обратное -- загрузка на STD-диаграмму результатов работы с SDL-редактором. На поведенческую модель Real сильно повлияла технология SDL/PLUS 20: так же не используются типы данных и выражения SDL, но применяется более гибкая стратегия связи с языками реализации [7] вместо заранее фиксированного языка [11].

1.5.3. Вывод.

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

1.6. Постановка задачи курсового проекта.

Перед созданием программной системы реального времени был проведен анализ действующих в данный момент разработок данного направления. Он показал, что существующий спектр ОС может обеспечить все потребности задач реального времени. Выбор системы (если абстрагироваться от цены, условий поставки и т.д.) диктуется только тем обстоятельством, удовлетворяет ли она условиям стоящей задачи. Например, если необходима хорошая операционная поддержка сетевых средств, то целесообразно использовать QNX - многозадачную операционную систему жесткого реального времени с архитектурой на основе микроядра. Если необходима очень высокая скорость реакции системы, можно использовать VxWorks. В данной работе при создании очень небольшой, не слишком сложной, встроенной прикладной программы было решено ориентироваться LynxOS, относящуюся к классу Unix'ов реального времени.

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

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

На основе планировщика будет реализован протокол, требующий поддержки реального времени. Для проектирования его реализации будет использована объектно-ориентированная методология. Такая методология характеризует скорее подход к планированию приложения, чем используемые средства языка, т.к. в авиационных системах, к которым и принадлежит реализуемый протокол A415 ARINC, не разрешено использование памяти из «кучи». В то время как динамическое выделение памяти является немаловажной частью использования языков, подобных C++ или Java.

2. Модели и методы предметной области.

2.1. Определения.

Сначала рассмотрим основное определение, вокруг которого и построена данная работа. Оно дано американским учёным Дональдом Гиллисом (Donald Gillies).

· Система реального времени - это система, в которой правильность вычислений зависит не только от логической корректности результата, но и от времени, в течение которого этот результат получен. Система работает неверно, если ее временные параметры не соответствуют заданным.

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

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

· Событие -- получение сообщения или окончание срока действия таймера.

· Действие -- посылка сообщения, установка таймера, блок кода на целевом языке.

· Время прибытия задачи - время, когда возникает необходимость в выполнении данной задачи.

· Вызов задачи - начало выполнения данной задачи после прибытия.

· Планировщик - механизм, который определяет, какой результат должен быть вычислен и в какое время. Результат работы планировщика называется расписанием.

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

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

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

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

· Многопользовательская ОС - операционная система, ориентированная на одновременную работу с несколькими пользователями.

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

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

2.2. Принципиальная структура.

2.2.1. Среда исполнения.

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

· небольшая память системы - для возможности ее встраивания;

· система должна быть полностью резидентна в памяти, чтобы избежать замещения страниц памяти или подкачки;

· система должна быть многозадачной - для обеспечения максимально эффективного использования всех ресурсов системы;

· ядро с приоритетом на обслуживание прерывания.

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

· диспетчер с приоритетом.

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

Сочетание описанных выше свойств создает мощную и эффективную среду исполнения в реальном времени.

2.2.2. Ядро систем реального времени.

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

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

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

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

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

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

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

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

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

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

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

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

2.2.3. Пикоядро.

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

· Не имеет каких-либо состояний (начальных, конечных или промежуточных), ядро без состояния. Не требует инициализации и деинициализации.

· Реализует и содержит в себе очень малое количество функций и данных - только функции для работы с объектами.

· Предоставляет объектно-ориентированный интерфейс системе в виде небольшого количества системных вызовов для работы с объектами.

· Является полностью пассивной частью кода операционной системы - код ядра выполняется только во время системных вызовов.

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

2.3. Методы управления задачами в ОС РВ.

2.3.1. Классификация подходов.

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

2.3.1.1. Статическое планирование.

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

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

2.3.1.2. Динамическое планирование.

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

2.3.1.3. Планирование, основанное на времени.

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

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

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

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

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

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

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

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

2.3.1.5. Планирование, управляемое приоритетами.

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

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

2.3.2. Обзор методов.

2.3.2.1. Rate-monotonic (RM).

Метод назначает статические приоритеты задачам основываясь на их периодах. В этом методе приоритеты определяются следующим образом: задача с самым маленьким периодом получает самый высокий приоритет.

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

Исходный RM подход имеет ряд ограничений:

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

· Все задачи должны быть периодическими.

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

· Время выполнения постоянно.

· Для задач определено время выполнения в худшем случае.

· Все задачи имеют крайний срок, эквивалентный их периоду.

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

Так в протоколе приоритетных границ (Priority Ceiling Protocol) и некоторых других похожих (Stack Resource Protocol) удалось избавиться от ограничения на взаимодействие задач. Также было предложено много методов приведения непериодических задач к периодическим.

2.3.2.2. Deadline Monotonic (DM).

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

Такой метод расстановки приоритетов будет оптимальным, если выполняются следующие условия:

· множество задач - фиксированное множество жёстких задач;

· задачи периодические или спорадические;

· задачи имеют определённое (известное) время выполнения в худшем случае;

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

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

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

2.3.2.3.1. Метод фонового выполнения.

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

2.3.2.3.2. Метод опроса.

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

Оба этих метода неэффективны, когда время ответа апериодической задачи важно.

2.3.2.3.3. Алгоритм безотлагательного сервера (IS)

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

2.3.2.3.4. Последний шанс.

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

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

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

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

2.3.2.4. EDF.

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

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

2.3.2.5. Сервер, допускающий задержку (DS) и Алгоритм обмена приоритетами (PE).

Страницы: 1, 2, 3