10.2. Планирование реального времени

Введение

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

Вычисления реального времени — тип вычислений, в которых корректность системы зависит не только от логического результата вычислений, но и времени получения этого результата. Мы можем определить систему реального времени путем определения того, что же собой представляет процесс, или задача реального времени. Вообще говоря, в системах реального времени часть задач являются задачами реального времени, у каждой из которых своя степень срочности. Такие задачи пытаются управлять событиями или реагировать на события, происходящие во внешнем мире. Поскольку эти события происходят в "реальном времени", то и задачи, связанные с ними, не должны отставать от реальных событий. Следовательно, с каждой задачей можно связать предельный срок, определяющий время начала (или завершения) задачи. Такие задачи можно охарактеризовать как жесткие и мягкие. Жесткие задачи реального времени (hard real-time task) представляют собой задачи, которые должны соответствовать этим предельным срокам; в противном случае неизбежны нежелательные повреждения или фатальные сбои системы. Мягкие задачи реального времени (soft real-time task) также имеют предельные сроки, но их выполнение — скорее пожелание, чем обязанность; если даже такая задача превысила отведенное ей время, ее все равно имеет смысл продолжать планировать и довести до завершения. Еще одной характеристикой задач реального времени является их периодичность. Непериодические задачи имеют предельные сроки начала или конца работы (или и те, и другие); в периодических задач требования могут быть указаны в виде "один раз за период Т" или "точно за Т единиц времени".

Характеристики операционных систем реального времени

Операционные системы реального времени должны удовлетворять следующим требованиям [MORG92]:

• детерминизм;

• чувствительность;

• управление со стороны пользователя;

• надежность

• восстановление после сбоев.

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

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

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

1. Количество времени, требующееся для начальной обработки прерывания и начала выполнения подпрограммы обработки прерывания (interrupt service routine — ISR). Если выполнение ISR требует переключения процессов, то задержка оказывается большей, чем при ISR, которая может выполняться в пределах контекста текущего процесса.

2. Количество времени, требующееся для выполнения ISR. Обычно это время зависит от используемой аппаратной платформы.

3. Влияние вложенных прерываний. Если ISR может быть прервана поступлением нового прерывания, то обслуживание текущего прерывания будет отложено.

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

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

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

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

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

Для того чтобы соответствовать приведенным требованиям, современная система реального времени обычно включает [STAN89];

• быстрое переключение процессов и/или потоков;

• малый размер (с минимальной функциональностью);

• способность быстрого отклика на внешние прерывания;

многозадачность со средствами взаимодействия процессов (такими, как семафоры, сигналы, события);

• использование специальных последовательных файлов, способных к накоплению данных с высокой скоростью;

• вытесняющее планирование на основе системы приоритетов;

• минимизация периодов времени, когда прерывания запрещены;

• наличие примитивов для задержки выполнения задачи на определенное время, а также приостановки и продолжения выполнения;

• специализированные таймеры и системы тайм-аутов.

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

Большинство современных операционных систем реального времени не работают с предельным временем непосредственно. Вместо этого они разработаны таким образом, чтобы обеспечить их максимальную чувствительность, с тем чтобы при наступлении предельного времени задача немедленно поступала на выполнение. С этой точки зрения приложения реального времени обычно требуют, чтобы детерминированное время отклика находились а интервале от долей миллисекунд до нескольких миллисекунд при широком диапазоне условий. Некоторые специализированные приложения, например в моделировании военных самолетов, часто налагают ограничение от 10 до 100 микросекунд [ALTA89].

На рис. 10.4 продемонстрирован ряд возможных вариантов планирования реального времени. В вытесняющем планировщике с использованием круговой стратегии задача реального времени добавляется к очереди готовых к выполнению задач, ожидающих наступления следующего кванта времени (см. рис. 10-4, а). В этом случае время планирования в целом неприемлемо для приложений реального времени. В не вытесняющем планировщике мы можем использовать механизм приоритетного планирования, дающий заданиям реального времени наивысший приоритет. В этом случае готовые задания реального времени будут выполняться сразу же после блокирования текущего процесса либо выполнения его до конца (рис. 10.4,6). Такая методика может привести к большим, до нескольких секунд, задержкам при выполнении в критический момент медленной низкоприоритетной задачи, так что этот подход также неприменим. Более приемлемый подход состоит в комбинировании приоритетов с прерываниями таймера. При этом точки вытеснения равноудалены друг от друга. При достижении точки вытеснения выполняющееся в настоящий момент задание вытесняется, если в наличии имеется более высокоприоритетное задание в состоянии ожидания; таким образом, вытеснение заданий в этом случае оказывается частью ядра операционной системы. Здесь задержки могут быть порядка нескольких миллисекунд (рис. 10.4,в). Для ряда приложений реального времени задержки такого уровня вполне адекватны, но могут оказаться неприемлемыми для более требовательных приложений. В таком случае можно применить подход, иногда именуемый немедленным вытеснением. Он заключается в том, что операционная система отвечает на прерывание практически немедленно, если только она не выполняет код критического раздела, который не может быть прерван. Задержки планирования при этом снижаются до 100 микросекунд и менее.

Планирование реального времени

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

В обзоре алгоритмов планирования реального времени [RAMA94] замечено. что различные алгоритмы планирования зависят от того, (1) выполняет ли система анализ планируемости, и если да, то (2) выполняется он статически или динамически и (3) приводит ли он к непосредственному выполнению функции планирования или же к построению расписания, согласно которому в процессе работы осуществляется диспетчеризация заданий. На основе этого автор определяет следующие классы алгоритмов.

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

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

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

• Динамическое планирование наилучшего результата. При этом анализ осуществимости планирования не выполняется; система пытается удовлетворить все предельные сроки и снимает те выполняющиеся процессы, предельные сроки которых нарушены.

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

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

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

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

Планирование с предельными сроками

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

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

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

• Предельное время начала выполнения. Время, когда должно начаться выполнение задания.

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

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

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

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

• Структура подзадач. Задача может быть разбита на обязательные и необязательные подзадачи. Жесткие предельные сроки при таком разделении имеют только обязательные подзадачи.

Можно показать, что для заданной стратегии вытеснения и использования либо предельного времени начала выполнения, либо предельного времени завершения применение планирования, выбирающего для выполнения задание с наиболее ранним предельным временем, минимизирует долго заданий с нарушенными временными ограничениями [BUTT99, HONG89, PANW88]. Этот вывод справедлив как для однопроцессорных, так и для многопроцессорных систем. Еще одним критическим вопросом является вытеснение. Если определяется предельное время начала работы, то имеет смысл применение невытесняющего планирования. В этом случае желательно, чтобы задания реального времени по­сле завершения обязательной или критической части самостоятельно блокирова­лись, позволяя выполняться другим заданиям реального времени с предельным временем начала работы (см. рис. 10.4,6). Для системы с предельным временем завершения более подходит вытесняющая стратегия (рис. 10А,в, г). Например, если выполняется задание X, а задание Y находится в состоянии готовности, то может возникнуть ситуация, когда единственным путем для удовлетворения ог­раничений обоих заданий будет вытеснение X, выполнение Y до завершения, и затем возобновление выполнения X.

В качестве примера планирования периодических заданий с предельным временем завершения рассмотрим систему, которая собирает и обрабатывает данные от двух датчиков, А и В. Сроки сбора данных от датчика А — каждые 20 ms, датчика В — каждые 50 ms. Процесс снятия данных, включая накладные расходы операционной системы, занимает для датчика А 10 ms, а для датчика В — 25 ms. В табл. 10.2 приведен профиль выполнения этих двух заданий.

Таблица 10.2. Профиль выполнения двух периодических заданий

Процесс	Время поступления	Время выполнения	Предельное время окончания
А(1)	0	10	20
А(2)	20	10	40
А(3)	40	10	60
А(4)	602	10	80
А(5)	80	10	100
. . .
В(1)	0	25	50
В(2)	50	25	100
. . .

Компьютер может принимать решение о планировании каждые 10 ms. Предположим, что при этих условиях мы используем схему планирования с приоритетами. Результат показан на первых двух временных диаграммах на рис. 10.5. Если А имеет более высокий приоритет, задание В1 получит только 20 ms процессорного времени в двух смежных интервалах по 10 ms; после этого будет достигнуто предельное время его выполнения, и задание выполнено не бу­дет. Если более высокий приоритет получит задание В, то выполниться в срок не сможет задание А1, Третья временная диаграмма показывает применение в дан­ной ситуации планирования с наиболее ранним предельным сроком. В момент времени t = 0 поступают задания А1 и В1, Поскольку предельный срок А1 наступает раньше предельного срока В1, сперва выполняется задание А1. После его завершения начинается выполнение В1, В момент времени t= 20 в систему поступает задание A3, предельный срок которого наступает раньше предельного срока В1. Соответственно, задание В1 прерывается, и начинается выполнение задания А2. Выполнение В1 продолжается, начиная с момента t = 30. В момент t = 40 в систему поступает задание A3, предельный срок которого, однако, более поздний, чем предельный срок задания В1, так что задание В1 продолжает выполнение до завершения в момент времени t = 45. В этот момент начинается

выполнение задания A3, завершающееся к моменту t = 55.

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

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

Таблица 10.3. Профиль выполнения пяти непериодических заданий

Процесс	Время поступления	Время выполнения	Предельное время начала работы
А	10	20	110
В	20	20	20
С	40	20	50
D	50	20	90
Е	60	20	70

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

Частотно-монотонное планирование

Одним из многообещающих методов разрешения конфликтов многозадачного планирования для периодических задач является частотно-монотонное планирование (rate monotonic scheduling — RMS). Эта схема была впервые предложена в [LIU73], но популярность приобрела только недавно [BRIA99, SHA94]. Схема RMS назначает приоритеты заданиям на основе их периодов.

На рис. 10.7 проиллюстрированы параметры периодических заданий. Период задания Т представляет собой интервал времени между поступлениями двух последовательных заданий одного типа. Частота заданий (измеряемая в Hz) представляет собой величину, обратную периоду (в секундах). Например, задание с периодом 50 ms имеет частоту 20 Hz. Обычно окончание периода задания является жестким предельным сроком завершения задания, хотя некоторые задания могут иметь и более ранние предельные сроки. Время выполнения (вычисления) С представляет собой количество процессорного времени, требующегося для каждого задания определенного типа. Очевидно, что в однопроцессорной системе время выполнения не должно превышать период заданий (т.е. должно выполняться С <=Т). Если периодическое задание всегда выполняется до полного завершения, т.е. если не имеется отклоненных из-за нехватки вычислительного ресурса заданий, то загруженность процессора этим заданием равна U = С/Т . Например, если задание имеет период 80 ms и время выполнения 55 ms, то загруженность им процессора составляет 55/80 = 0.6875.

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

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

(10.1)

Сумма загруженности процессора разными заданиями не может превышать 1, что соответствует полной загрузке процессора. Неравенство (10.1) определяет верхнюю границу количества заданий, которые может успешно обслуживать идеальный алгоритм планирования. Для конкретного реального алгоритма граница может оказаться ниже. Так, можно показать, что для алгоритма RMS справедливо следующее неравенство:

(10.2)

В табл. 10.4 приведены некоторые значения верхней границы для метода RMS. При возрастании количества заданий верхняя граница стремится к значению ln 2 ≈0.693. .

Таблица 10.4. Значения верхней границы загруженности для метода RMS

n
1	1.000
2	0.828
3	0.779
4	0.756 Г 1 2" < -)
5	0.743
6	0.734
. . .	. . .
∞	ln 2 ≈0.693

В качестве примера рассмотрим три периодических задания.

• Задание P₁: C₁ = 20; T₁ = 100; U₁ = 0.2.

• Задание P₂: C₂ = 40; T₂ = 150; U₂ = 0.267.

• Задание Р₃: С₃ = 100; Т₃ = 350; U₃ = 0.286.

Общая загруженность процессора этими тремя заданиями составляет 0.2+0.267+0.286 = 0.753. Верхняя граница загруженности этих трех задач при использовании метода RMS составляет

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

Можно также показать, что верхняя граница из (10.1) справедлива для метода наиболее раннего предельного срока. Таким образом, при применении планирования с наиболее ранним предельным сроком можно достичь более высокой загрузки процессора и, соответственно, обработать большее количество заданий. Тем не менее метод RMS широко распространен и используется во многих промышленных приложениях. В работе [SHA91] это поясняется следующими причинами.

1. На практике отличие производительности невелико. Кроме того, неравенство (10.2) консервативно, и на практике зачастую достигается 90%-ная загрузка процессора.

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

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