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

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РФ 

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ АВТОНОМНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ  
ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ  
«НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ ТЕХНОЛОГИЧЕСКИЙ УНИВЕРСИТЕТ «МИСиС» 

 

 
 
 

 

 

 

 
 

 

 

Кафедра интеллектуальных систем управления

Ю.А. Турицын 
Б.Ф. Коньшин 
И.С. Бондаренко 
И.В. Баранникова 

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

 

Методическое пособие 

 

Москва  2015 

УДК 004.7 
 

Р е ц е н з е н т ы  
д-р техн. наук, проф. Л.Д. Певзнер (зав. кафедрой «Автоматика  
и управление в технических системах» ИТАСУ НИТУ «МИСиС»); 
канд. техн. наук, доц. Фролов С.В.  
(нач. отд. сопровождения проектов ЗАО «ПРОМТЕХ») 

Турицын, Ю.А. 
 
Системы 
реального 
времени : методическое 
пособие / 
Ю.А. Турицын, Б.Ф. Коньшин, И.С. Бондаренко, И.В. Баранникова. – М. : Изд. Дом МИСиС, 2015. – 148 с. 
 

Методическое пособие ориентировано на студентов специальности 
220000 «Интеллектуальные системы управления», изучающих дисциплину 
«Системы реального времени» по рекомендованной Министерством образования Российской Федерации программе. Методическое пособие может быть 
использовано при курсовом проектировании, самостоятельной работе студентов и при проведении практических и лабораторных занятий. Пособие 
будет полезным для студентов заочного отделения, обучающихся по программе бакалавров направления «Информатика и вычислительная техника» 
(552800). 
УДК 004.7 

 
© Ю.А. Турицын, 
Б.Ф. Коньшин, 
И.С. Бондаренко, 
И.В. Баранникова, 2015 

ОГЛАВЛЕНИЕ 

1. Аппаратно-программные средства  
и комплексы реального времени.............................................................4 
1.1. Определение и основные особенности систем  
реального времени................................................................................4 
1.2. Классы систем реального времени.............................................17 
2. Устройства связи с объектом.............................................................32 
2.1. Методы и средства обработки асинхронных событий.............32 
2.2. Управление задачами ..................................................................43 
2.3. Управление системными ресурсами..........................................52 
2.4. Управление оперативной памятью ............................................60 
2.5. Переходные процессы в логических схемах. Гонки. ...............70 
3. Операционные системы реального времени....................................86 
3.1. Архитектура систем реального времени ...................................86 
3.2. Механизмы синхронизации и взаимодействия процессов ......97 
3.3. Механизмы защиты ресурсов...................................................107 
3.4. Обмен информацией между процессами ................................114 
4. Проектирование систем реального времени..................................121 
4.1. Методика комплексного проектирования  
и отладки систем реального времени .............................................121 
4.2. Аппаратные средства поддержки проектирования  
и отладки систем реального времени .............................................127 
Список литературы...............................................................................147 
 

1. АППАРАТНО-ПРОГРАММНЫЕ СРЕДСТВА 
И КОМПЛЕКСЫ РЕАЛЬНОГО ВРЕМЕНИ 

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

1. Определение систем реального времени. 
2. Требования, предъявляемые к системам реального времени. 
3. Основные области применения систем реального времени. 
4. Аппаратурная среда систем реального времени. 

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

Существует несколько определений систем реального времени 
(СРВ) (real time operating systems (RTOS)), большинство из которых 
противоречит друг другу. Приведем некоторые из них, чтобы продемонстрировать различные взгляды на назначение и основные задачи 
СРВ: 
1. Системой реального времени называется система, в которой успешность работы любой программы зависит не только от ее логической правильности, но и от времени, за которое она получила результат. Если временные ограничения не удовлетворены, то фиксируется 
сбой в работе систем. 
Таким образом, временные ограничения должны быть гарантированно удовлетворены, что требует от системы предсказуемости, т.е. 
способности вне зависимости от своего текущего состояния и загруженности выдавать нужный результат за требуемое время. При этом 
желательно, чтобы система обеспечивала как можно больший процент использования имеющихся ресурсов. 
Примером задачи, где требуется СРВ, является управление роботом, берущим деталь с ленты конвейера. Деталь движется, и робот 
имеет лишь небольшое временное окно, когда он может ее взять. Если он опоздает, то деталь уже не будет на нужном участке конвейера 
и, следовательно, работа не будет сделана, несмотря на то, что робот 
находится в правильном месте. Если он позиционируется раньше, то 
деталь не успеет подъехать и он заблокирует ей путь. 
Другим примером может быть космический аппарат, находящийся 
на автопилоте. Сенсорные серводатчики должны постоянно передавать 
в управляющий компьютер результаты измерений. Если результат какого-либо измерения будет пропущен, то это может привести к недо

пустимому несоответствию между реальным состоянием систем космического аппарата и информацией о нем в управляющей программе. 
Различают сильное (hard) и слабое (soft) требование реального 
времени. Если запаздывание программы приводит к полному нарушению работы управляемой системы, то говорят о сильном реальном 
времени (жесткие СРВ). Если же запаздывание ведет только к потере 
производительности, то говорят о слабом реальном времени (мягкие 
СРВ). Большинство программного обеспечения ориентировано на 
слабое реальное время, а задача хорошей СРВ – обеспечить уровень 
безопасного функционирования системы, даже если управляющая 
программа никогда не закончит своей работы. 
2. Стандарт POSIX 1003.1 определяет СРВ следующим образом: 
«Реальное время в операционных системах – это способность операционной системы обеспечить требуемый уровень сервиса в заданный 
промежуток времени». 
3. Иногда системами реального времени называют системы постоянной готовности (online-системы) или «интерактивные системы 
с достаточным временем реакции». Обычно это делают фирмыпроизводители по маркетинговым соображениям. Если интерактивную программу называют работающей в реальном времени, то это 
означает, что она успевает обрабатывать запросы от человека, для 
которого задержка в сотни миллисекунд даже незаметна. 
4. Часто понятие «система реального времени» отождествляют с 
понятием «быстрая система». Это не всегда правильно. Время задержки реакции СРВ на событие не так уж важно (оно может достигать нескольких секунд). Главное, чтобы это время было достаточно 
для рассматриваемого приложения и гарантированно. Часто алгоритм с гарантированным временем работы менее эффективен, чем 
алгоритм, таким свойством не обладающий. Например, алгоритм 
«быстрой» сортировки (quicksort) в среднем работает значительно 
быстрее многих других алгоритмов сортировки, но его гарантированная оценка сложности значительно хуже. 
5. Во многих важных сферах приложения СРВ вводятся свои понятия «реального времени». Так, процесс цифровой обработки сигнала называют идущим в «реальном времени», если анализ (при вводе) и/или генерация (при выводе) данных могут быть проведены за 
то же время, что и анализ и/или генерация тех же данных без цифровой обработки сигнала. 
Например, если при обработке аудио данных требуется 2,01 с для 
анализа 2,00 с звука, то это не процесс реального времени. Если же 

требуется 1,99 с, то это процесс реального времени. Исходя из вышесказанного, дадим определение системы реального времени в следующей интерпретации. 
Определение. Система реального времени реагирует в предсказуемое время на непредсказуемое появление внешних событий. 
Это определение предъявляет к системе вполне определенные базовые требования. Рассмотрим эти требования. 

2. Требования, предъявляемые  
к системам реального времени  

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

Таким образом, различие между системами жесткого и мягкого 
реального времени определяется следующими требованиями: система называется системой жесткого реального времени, если она 
«не имеет права опаздывать», и мягкого реального времени – 
если ей «не следует опаздывать». 
Введем понятие операционной системы (ОС). Операционная система – это комплекс программ для управления и координации работы 
всех устройств системы, управления процессом выполнения прикладных программ и обеспечения диалога с пользователем. 
Не существует операционных систем жесткого или мягкого реального времени. Понятия системы реального времени и операционной системы реального времени (ОСРВ) часто смешиваются. 
Система реального времени – это конкретная система, связанная с 
реальным объектом. Она включает в себя необходимые аппаратные 
средства, операционную систему и прикладное программное обеспечение. 
Операционная система реального времени – это только инструмент, помогающий построить конкретную систему реального времени. Поэтому бессмысленно говорить об операционных системах жесткого или мягкого реального времени. Можно говорить только о 
том, можно ли с помощью данной операционной системы построить 
систему реального времени. Конкретная ОСРВ может только предоставить возможность создать систему жесткого реального времени. 
Но обладание такой ОСРВ вовсе не делает систему «жесткой». Для 
создания системы жесткого реального времени необходимо сочетание подходящих аппаратных средств, адекватной операционной системы и правильного проектирования прикладного программного 
обеспечения. 
Если, например, принято решение построить систему реального 
времени, обслуживающую TCP/IP-соединение через Ethernet, то система никогда не будет системой жесткого реального времени, поскольку сам Ethernet непредсказуем. В данном случае, основное ограничение на создание СРВ накладывает метод случайного доступа 
CSMA/CD. 
Если, с другой стороны, вы создаете приложение над такой ОС, 
как «Windows 3.11», то ваша система никогда не будет системой жесткого реального времени, поскольку непредсказуемо поведение 
операционной системы. 
Согласно определению, СРВ должна «обеспечить требуемый уровень сервиса в заданный промежуток времени». Этот промежуток 

времени обычно задается периодичностью и скоростью процессов, 
которыми управляет система. Приведем типичные времена реакции 
на внешние события в процессах, управляемых СРВ: 
– математическое моделирование – несколько микросекунд; 
– радиолокация – несколько миллисекунд; 
– складской учет – несколько секунд; 
– торговые операции – несколько минут; 
– управление производством – несколько минут; 
– химические реакции – несколько часов. 
Видно, что времена сильно разнятся и накладывают различные 
требования на вычислительную установку, на которой работает СРВ. 
Различная предметная область использования СРВ предъявляет к 
системам в каждом конкретном случае различные временные требования. 
Интервал между поступлениями сообщений в ЭВМ может быть 
случайным и определяться внешними факторами, такими как нажатие клавиши оператором, или он может быть циклическим и управляться от часов или от сканирующего механизма в ЭВМ. Так же, как 
и время ответа, этот интервал может изменяться от доли миллисекунд до получаса и более. 
Определим операционную систему реального времени как операционную систему, с помощью которой можно построить систему жесткого реального времени. Обязательные требования к ОСРВ: 
Требование 1: ОСРВ должна быть многонитиевой или многозадачной и поддерживать диспетчеризацию с вытеснением. 
Поведение ОСРВ должно быть предсказуемым. Это не означает, 
что ОСРВ должна быть быстрой, но означает, что максимальный 
промежуток времени для выполнения любой операции должен быть 
известен заранее и согласован с требованиями приложения. Например, Windows 3.11 – даже на процессоре Pentium Pro с тактовой частотой 200 МГц – неприменима для построения систем реального 
времени, поскольку одно приложение может навсегда захватить 
управление и заблокировать все остальные приложения. 
Первое требование состоит в том, чтобы такая ОС была многонитиевой или многозадачной, а, кроме того, планировщик должен 
иметь возможность вытеснять любую нить (задачу) и передавать 
управление той нити (задаче), которая больше всего в этом нуждается. Для обеспечения вытеснения на уровне прерываний структура 
обслуживания прерываний (в том числе и аппаратная архитектура) 
должна быть многоуровневой. 

Требование 2: Должно существовать понятие приоритета нити (задачи). 
Как найти нить (задачу), которая нуждается в ресурсах больше 
всего? В идеальном случае ОСРВ предоставляет ресурсы той задаче 
или драйверу, у которых осталось меньше всего времени до истечения срока реакции на событие (назовем такую ОС – ОС, управляющей критическими сроками). Однако для реализации этого механизма нужно уметь прогнозировать, сколько времени понадобится задаче для завершения своей работы и сколько времени понадобится 
другим задачам для того, чтобы они успели к своим критическим 
срокам. Подобная ОСРВ пока еще не создана из-за сложности реализации. Поэтому разработчики ОС используют другой метод: они вводят концепцию приоритетов для нитей (задач). 
При построении конкретной системы реального времени разработчик должен выстроить приоритеты задач таким образом, чтобы 
каждая из них успела с реакцией к своему критическому сроку, т.е. 
он должен трансформировать базовое требование реального времени 
«успеть с реакцией к нужному моменту» в комбинацию приоритетов 
и в сценарий их динамического изменения. Очевидно, что при этой 
трансформации возможны ошибки, приводящие к неправильной работе системы. Для решения этого вопроса используют различные 
теории, такие как теория монотонного планирования или различные 
методы и средства моделирования. Однако эти методы оказываются 
не всегда эффективными. Как бы то ни было, во всех современных 
ОСРВ приходится использовать механизм приоритетов как один из 
инструментов предсказуемости поведения системы. На сегодняшний 
день не имеется другого решения, понятие приоритета потока для 
систем реального времени неизбежно. 
Требование 3: ОС должна поддерживать предсказуемые механизмы синхронизации нитей (задач). 
Все нити (задачи) разделяют данные (ресурсы) и должны обмениваться между собой информацией, поэтому необходимы механизмы 
межзадачного (межнитиевого) взаимодействия. 
Требование 4: Должен существовать механизм наследования 
приоритетов (система должна быть защищена от инверсии приоритетов). 
Под инверсией приоритетов будем понимать изменение их обычного порядка. На самом деле именно эти механизмы синхронизации 
и тот факт, что разные нити выполняются в одном и том же про

странстве памяти, и определяют различие между нитями и процессами. Процессы не разделяют одно и то же пространство памяти. 
Комбинации приоритетов нитей и разделение между ними ресурсов приводят к классической проблеме инверсии приоритетов. Для 
создания условия инверсии приоритетов должно быть задействовано 
как минимум три нити. Если нить с самым низким приоритетом заблокировала ресурс (который она делит с самой высокоприоритетной нитью), в то время как работает нить с промежуточным приоритетом, возникает следующий эффект: нить с наивысшим приоритетом ожидает освобождения ресурса; нить с промежуточным приоритетом вытесняет низкоприоритетную нить и работает, пока не завершится; управление получает низкоприоритетная нить, которая освобождает ресурс, и только после этого нить с высоким приоритетом 
может продолжить свою работу. В этом случае время, необходимое 
для завершения нити с наивысшим приоритетом, зависит от времени 
работы нити с более низким приоритетом – это и есть инверсия приоритетов. Очевидно, что в такой ситуации высокоприоритетная нить 
может «прозевать» критическое событие. 
Чтобы избежать таких ситуаций, ОСРВ должна быть снабжена 
механизмом наследования приоритетов, т.е. блокирующая нить 
должна наследовать приоритет нити, которую она блокирует (конечно, только в том случае, если заблокированная нить имеет более высокий приоритет). Поведение ОС должно быть предсказуемо. Наследование означает, что блокирующий ресурс тред наследует приоритет треда, который он блокирует (это справедливо лишь в том случае, если блокируемый тред имеет более высокий приоритет). 
Здесь есть еще одна проблема: количество возможных приоритетов очень мало. Большинство современных ОСРВ допускают использование как минимум 256 приоритетов. В чем суть проблемы? 
Ответ очевиден: чем больше приоритетов в распоряжении проектировщика, тем более предсказуемую систему можно создать. При оптимальном проектировании системы различным нитям присваиваются различные приоритеты. 
Рассмотрим временные требования к операционным системам. 
Разработчик должен знать все времена выполнения системных вызовов и уметь предсказывать поведение системы в любых ситуациях. 
Поэтому производитель ОСРВ обязательно должен давать информацию о следующих временных характеристиках системы: 
– задержке прерывания (interrupt latency) – т.е. время от момента 
появления запроса на прерывание до начала его обработки;