Министерство образования и науки Российской Федерации

УФИМСКИЙ ГОСУДАРСТВЕННЫЙ АВИАЦИОННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ

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

А.М.СУЛЕЙМАНОВА

СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ

Учебное пособие

Уфа 2004

www.pdffactory.com

Составитель А.М. Сулейманова УДК 004.415.2 ББК 32.973.26-018.1

Сулейманова А.М. Системы реального времени: учебное посо- бие/ Уфимск. гос. авиац. техн. ун-т.– Уфа, 2004.– 292 с.

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

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

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

Предназначено для студентов специальностей «Автоматизиро- ванные системы обработки информации и управления» и «Приклад- ная информатика в экономике».

Библиогр.: 29 назв.

Научный редактор: канд.техн.наук, доцент М.Я.Парфенова

Рецензенты: канд.техн.наук, доцент, заведующая кафедрой Информатики БАГСУ С.М.Ибатуллина Канд.техн.наук, доцент, заместитель заведующего кафедрой Управления в ОВД В.А.Пестриков

©Уфимский государственный авиационный технический университет, 2004

www.pdffactory.com

www.pdffactory.com

www.pdffactory.com

11.1.Теория планирования в реальном времени . 258

11.2.Развитие теории планирования в реальном

www.pdffactory.com

11.3. Анализ производительности с помощью анализа последовательности событий ........ 274

11.4.Анализ производительности с помощью теории планирования в реальном времени

11.5.Пример анализа производительности с помощью анализа последовательности

11.6.Пример анализа производительности с применением теории планирования в

11.7.Анализ производительности по теории планирования в реальном времени и

www.pdffactory.com

Часть 1. СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ. ОПРЕДЕЛЕНИЯ. ОБЗОР. ОПЕРАЦИОННЫЕ СИСТЕМЫ

1. Что такое функционирование в «Реальном масштабе времени»

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

Толковый словарь по вычислительным системам [7], дает такое определение (стр. 399):

R.052 real-time system система реального времени (СРВ)

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

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

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

Втолковом словаре по информатике [8] дается такое определе- ние (стр. 335): Режим реального времени [real time processing]. Режим

www.pdffactory.com

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

числительной системы с внешними по отношению к ней процессами в темпе, соизмеримом со скоростью протекания этих процессов.

Каноническое определение системы реального времени дано Дональдом Гиллиесом и выглядит так:

«Системой реального времени является такая система, коррект- ность функционирования которой определяется не только корректно- стью выполнения вычислений, но и временем, в которое получен тре- буемый результат. Если требования по времени не выполняются, то считается, что произошел отказ системы». Другие добавляют: «По- этому необходимо, чтобы было гарантировано [аппаратными и про- граммными средствами и алгоритмами обработки] выполнение тре- бований по времени. Гарантия выполнения требований по времени необходима, чтобы поведение системы было предсказуемо. Также желательно, чтобы система обеспечивала высокую степень использо- вания ресурсов, чтобы удовлетворять требованиям по времени [с ми- нимальными затратами]».

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

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

Отметим следующую особенность: в примере с роботом и имеем настоящий, «жесткий» режим реального времени (hard real time), и если робот опоздает, то это приведет к полностью ошибочной опера- ции. Однако это мог бы быть режим «квазиреального» времени (soft real time), если бы опоздание робота приводило бы только к потере производительности. Многое из того, что сделано в области про- граммирования в реальном времени, в действительности работает в режиме «квазиреального» времени. Грамотно разработанные систе- мы, как правило, имеют уровень безопасности/коррекции поведения

www.pdffactory.com

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

Бывает, что термин «система реального времени» применяют в значении «интерактивная система» (on-line). Часто это просто рек- ламный ход. Например, системы заказа билетов или системы склад- ского учета не являются системами «реального времени», так как че- ловек-оператор без проблем перенесет задержку ответа на несколько сотен миллисекунд.

Также можно встретить случаи, когда термин «система реально- го времени» применяют просто в значении «быстродействующая сис- тема». Необходимо отметить, что определение «реального времени» не является синонимом для определения «быстродействующая». Еще раз: термин «система реального времени» не означает, что система дает ответ на воздействие мгновенно – задержка может достигать се- кунд и более – но означает тот факт, что гарантируется некоторая максимально возможная величина задержки ответа, что позволяет системе решать поставленную задачу. Необходимо также отметить, что алгоритмы, обеспечивающие гарантированное время ответа, час- то имеют меньшую среднюю производительность, чем алгоритмы, которые не гарантируют время ответа.

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

–термин «система реального времени» в настоящее время мо- жет быть записан так: “Системой реального времени является такая система, корректность функционирования которой определяется не только корректностью выполнения вычислений, но и временем, в ко- торое получен требуемый результат. Если требования по времени не выполняются, то считается, что произошел отказ системы”.

Для того чтобы система могла удовлетворить требованиям, предъявляемым к системам реального времени, аппаратные, про- граммные средства и алгоритмы работы системы должны гарантиро- вать заданные временные параметры реакции системы. Время реак- ции не обязательно должно быть очень маленьким, но оно должно быть гарантированным (и отвечающим поставленным требованиям);

–использование термина «система реального времени», опреде- ленного выше, для обозначения интерактивных и высокопроизводи- тельных систем неверно;

www.pdffactory.com

–термин «квазиреальное время» (soft real-time) хотя и использу- ется, но четко не определен. До его четкого определения вряд ли воз- можно его применение в документах (кроме рекламных). С уверен- ностью можно сказать, что смысл термина «реальное время» тракту- ется специалистами по-разному в зависимости от области их профес- сиональных интересов, от того, являются они теоретиками или прак- тиками, и даже просто отличного опыта и круга общения.

–практически все системы промышленной автоматизации явля- ются системами реального времени.

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

вреальном времени.

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

Интуитивно понятно, что быстродействие системы реального времени должно быть тем больше, чем больше скорость протекания процессов на объекте контроля и управления. Чтобы оценить необхо- димое быстродействие для систем, имеющих дело со стационарными процессами, часто используют теорему Котельникова [6], из которой следует, что частота дискретизации сигналов должна быть как мини- мум в 2 раза выше граничной частоты их спектра.

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

www.pdffactory.com

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

Принято различать системы «жесткого» и «мягкого» реального времени. Эти различия не связаны с органолептическими свойствами систем. Тогда что же это такое?

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

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

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

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

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

2.Точного определения для «мягкого» реального времени не существует, поэтому будем считать, что сюда относятся все системы реального времени, не попадающие в категорию «жестких».

Так как система «мягкого» реального времени может не успе- вать все делать ВСЕГДА в заданное время, возникает проблема опре- деления критериев успешности (нормальности) ее функционирова- ния. Вопрос этот совсем не простой, так как в зависимости от функ-

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

www.pdffactory.com

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

Примем как очевидные следующие моменты.

1.Когда-то операционных систем совсем не было.

2.Через некоторое время после их появления возникло направ- ление ОС РВ.

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

Четкой границы между ядром (Kernel) и операционной системой нет. Различают их, как правило, по набору функциональных возмож- ностей. Ядра предоставляют пользователю такие базовые функции, как планирование и синхронизация задач, межзадачная коммуника- ция, управление памятью и т.п. Операционные системы в дополнение

кэтому имеют файловую систему, сетевую поддержку, интерфейс с оператором и другие средства высокого уровня.

По своей внутренней архитектуре ОС РВ можно условно разде- лить на монолитные ОС, ОС на основе микроядра и объектно- ориентированные ОС. Графически различия в этих подходах иллюст- рируются рисунками 2.1, 2.2, 2.3. Преимущества и недостатки раз- личных архитектур достаточно очевидны, поэтому подробно мы на них останавливаться не будем.

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

www.pdffactory.com

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

Рис. 2.3. Объектно-ориентированная ОС РВ

www.pdffactory.com

2.1. Задачи, процессы, потоки

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

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

Принято различать две разновидности задач: процессы и потоки.

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

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

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

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

1. Так как множество потоков способно размещаться внутри од- ного EXE-модуля, это позволяет экономить ресурсы как внешней, так и внутренней памяти.

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

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

3.Как правило, контекст потоков меньше, чем контекст процес- сов, а значит, время переключения между задачами-потоками мень- ше, чем между задачами-процессами.

4.Так как все потоки, а иногда и само ядро РВ размещаются в одном ЕХЕ-модуле, значительно упрощается использование про- грамм-отладчиков (debugger).

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

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

www.pdffactory.com

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

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

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

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

2.2. Основные свойства задач

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

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

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

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

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

Контекст задачи – это набор данных, содержащий всю необхо-

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

www.pdffactory.com

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

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

1.Активная задача – это задача, выполняемая системой в теку- щий момент времени.

2.Готовая задача – это задача, готовая к выполнению и ожи- дающая у планировщика своей «очереди».

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

Пустая задача (Idle Task) – это задача, запускаемая самой опе-

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

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

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

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

Реентерабельность (повторная входимость) означает возмож-

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

www.pdffactory.com