Лекции по дисциплине системы реального времени тема аппаратнопрограммные средства и комплексы реального времени
 Скачать 1.67 Mb.
|
|
1 ЛЕКЦИИ ПО ДИСЦИПЛИНЕ «СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ» ТЕМА 1. АППАРАТНО-ПРОГРАММНЫЕ СРЕДСТВА И КОМПЛЕКСЫ РЕАЛЬНОГО ВРЕМЕНИ Лекция 1.1. Определение и основные особенности систем реального времени 1. Определение систем реального времени. 2. Требования, предъявляемые к системам реального времени. 3. Основные области применения систем реального времени. 4. Аппаратурная среда систем реального времени. 1. Определение систем реального времени Существует несколько определений систем реального времени (СРВ) (real time operating systems (RTOS)), большинство из которых противоречит друг другу. Приведем некоторые из них, чтобы продемонстрировать раз- личные взгляды на назначение и основные задачи СРВ: 1. Системой реального времени называется система, в которой успеш- ность работы любой программы зависит не только от ее логической пра- вильности, но и от времени, за которое она получила результат. Если вре- менные ограничения не удовлетворены, то фиксируется сбой в работе систем. Таким образом, временные ограничения должны быть гарантированно удовлетворены. Это требует от системы быть предсказуемой, то есть вне за- висимости от своего текущего состояния и загруженности выдавать нужный результат за требуемое время. При этом желательно, чтобы система обеспе- чивала как можно больший процент использования имеющихся ресурсов. Примером задачи, где требуется СРВ, является управление роботом, берущим деталь с ленты конвейера. Деталь движется, и робот имеет лишь небольшое временное окно, когда он может ее взять. Если он опоздает, то деталь уже не будет на нужном участке конвейера, и, следовательно, работа не будет сделана, несмотря на то, что робот находится в правильном месте. Если он позиционируется раньше, то деталь еще не успеет подъехать, и он заблокирует ей путь. Другим примером может быть космический аппарат, находящийся на автопилоте. Сенсорные серводатчики должны постоянно передавать в управ- ляющий компьютер результаты измерений. Если результат какого-либо из- мерения будет пропущен, то это может привести к недопустимому несоот- ветствию между реальным состоянием систем космического аппарата и ин- формацией о нем в управляющей программе. Различают сильное (hard) и слабое (soft) требование реального време- ни. Если запаздывание программы приводит к полному нарушению работы управляемой системы, то говорят о сильном реальном времени (жесткие СРВ). Если же запаздывание ведет только к потере производительности, то говорят о слабом реальном времени (мягкие СРВ). Большинство программ- ного обеспечения ориентировано на слабое реальное время, а задача хорошей 2 СРВ - обеспечить уровень безопасного функционирования системы, даже если управляющая программа никогда не закончит своей работы. 2. Стандарт POSIX 1003.1 определяет СРВ следующим образом: «Ре- альное время в операционных системах - это способность операционной сис- темы обеспечить требуемый уровень сервиса в заданный промежуток време- ни». 3. Иногда системами реального времени называют системы постоян- ной готовности (on-line системы), или «интерактивные системы с достаточ- ным временем реакции». Обычно это делают фирмы-производители по мар- кетинговым соображениям. Если интерактивную программу называют рабо- тающей в реальном времени, то это означает, что она успевает обрабатывать запросы от человека, для которого задержка в сотни миллисекунд даже неза- метна. 4. Часто понятие «система реального времени» отождествляют с поня- тием «быстрая система». Это не всегда правильно. Время задержки реакции СРВ на событие не так уж важно (оно может достигать нескольких секунд). Главное, чтобы это время было достаточно для рассматриваемого приложения и гарантированно. Часто алгоритм с гарантированным временем работы менее эффективен, чем алгоритм, таким свойством не обладающий. Например, алгоритм «быстрой» сортировки (quicksort) в среднем работает значительно быстрее многих других алгоритмов сортировки, но его гарантированная оценка сложности значительно хуже. 5. Во многих важных сферах приложения СРВ вводятся свои понятия «реального времени». Так, процесс цифровой обработки сигнала называют идущим в «реальном времени», если анализ (при вводе) и/или генерация (при выводе) данных может быть проведен за то же время, что и анализ и/или ге- нерация тех же данных без цифровой обработки сигнала. Например, если при обработке аудио данных требуется 2,01 секунды для анализа 2,00 секунды звука, то это не процесс реального времени. Если же требуется 1,99 секунды, то это процесс реального времени. Исходя из выше сказанного, дадим определение системы реального времени в следую- щей интерпретации. Определение. Система реального времени реагирует в предсказуемое время на непредсказуемое появление внешних событий. Это определение предъявляет к системе вполне определенные базовые требования. Рассмотрим требования, предъявляемые к системам реального времени. 2. Требования, предъявляемые к системам реального времени Своевременная реакция. После того как произошло событие, реакция должна последовать не позднее, чем через требуемое время. Превышение этого времени рассматривается как серьезная ошибка. Одновременная обработка информации, которая характеризует изме- нение процесса нескольких событий. Даже если одновременно происходит несколько событий, реакция ни на одно из них не должна запаздывать. Это означает, что система реального времени должна иметь встроенный 3 параллелизм. Параллелизм достигается использованием нескольких процессоров в системе и/или многозадачным подходом. Рассмотрим основные признаки систем жесткого и мягкого реального времени. Признаки систем жесткого реального времени: . недопустимость никаких задержек, ни при каких условиях; . бесполезность результатов при опоздании; . катастрофа при задержке реакции; . цена опоздания бесконечно велика. Пример системы жесткого реального времени - бортовая система управления самолетом. Признаки систем мягкого реального времени: . за опоздание результатов приходится платить; . снижение производительности системы, вызванное запаздыванием реакции на происходящие события. Пример - автомат розничной торговли и подсистема сетевого интер- фейса. В последнем случае можно восстановить пропущенный пакет, ис- пользуя сетевой протокол, повторяющий передачу пропущенных пакетов. При этом, конечно, произойдет снижение производительности системы. Таким образом, различие между системами жесткого и мягкого реаль- ного времени определяется следующими требованиями: система называется системой жесткого реального времени, если она "не имеет права опаздывать", и мягкого реального времени - если ей "не следует опаз- дывать". Введем понятие операционной системы (ОС). Операционная система - это комплекс программ для управления и координации работы всех уст- ройств системы, управления процессом выполнения прикладных программ и обеспечения диалога с пользователем. Не существует операционных систем жесткого или мягкого реального времени. Понятия системы реального времени и операционной системы ре- ального времени (ОСРВ) часто смешиваются. Система реального времени - это конкретная система, связанная с ре- альным объектом. Она включает в себя необходимые аппаратные средства, операционную систему и прикладное программное обеспечение. Операционная система реального времени – это только инструмент, помогающий построить конкретную систему реального времени. Поэтому бессмысленно говорить об операционных системах жесткого или мягкого реального времени. Можно говорить только о том, можно ли с помощью данной операционной системы построить систему реального времени. Кон- кретная ОСРВ может только предоставить возможность создать систему же- сткого реального времени. Но обладание такой ОСРВ вовсе не делает систе- му "жесткой". Для создания системы жесткого реального времени необходи- мо сочетание подходящих аппаратных средств, адекватной операционной системы и правильного проектирования прикладного программного обеспе- чения. 4 Если, например, принято решение построить систему реального вре- мени, обслуживающую TCP/IP-соединение через Ethernet, то система никогда не будет системой жесткого реального времени, поскольку сам Ethernet непредсказуем. В данном случае, основное ограничение на создание СРВ оказывает метод случайного доступа CSMA/CD. Если, с другой стороны, вы создаете приложение над такой ОС, как "Windows 3.11", то ваша система никогда не будет системой жесткого реаль- ного времени, поскольку непредсказуемо поведение операционной системы. Согласно определению, СРВ должна «обеспечить требуемый уровень сервиса в заданный промежуток времени». Этот промежуток времени обычно задается периодичностью и скоростью процессов, которыми управляет система. Приведем типичные времена реакции на внешние события в про- цессах, управляемых СРВ: математическое моделирование - несколько микросекунд; радиолокация - несколько миллисекунд; складской учет - несколько секунд; торговые операции - несколько минут; управление производством - несколько минут; химические реакции - несколько часов. Видно, что времена сильно разнятся и накладывают различные требо- вания на вычислительную установку, на которой работает СРВ. Различная предметная область использования СРВ, предъявляет к системам в каждом конкретном случае различные временные требования. Интервал между поступлениями сообщений в ЭВМ может быть слу- чайным и определяться внешними факторами, такими, как нажатие клавиши оператором, или он может быть циклическим и управляться от часов или от сканирующего механизма в ЭВМ. Так же, как и время ответа, этот интервал может изменяться от доли миллисекунд до получаса и более. Определим операционную систему реального времени как операцион- ную систему, с помощью которой можно построить систему жесткого реаль- ного времени. Обязательные требования к ОСРВ: Требование 1: ОСРВ должна быть многонитиевой или многозадачной и поддерживать диспетчеризацию с вытеснением. Поведение ОСРВ должно быть предсказуемым. Это не означает, что ОСРВ должна быть быстрой, но означает, что максимальный промежуток времени для выполнения любой операции должен быть известен заранее и должен быть согласован с требованиями приложения. Например, Windows 3.11 - даже на процессоре Pentium Pro с тактовой частотой 200 МГц - непри- менима для построения систем реального времени, поскольку одно приложение может навсегда захватить управление и заблокировать все остальные приложения. Первое требование состоит в том, чтобы такая ОС была многонитие- вой или многозадачной и, кроме того, планировщик должен иметь возмож- ность вытеснять любую нить (задачу) и передавать управление той нити (за- даче), которая больше всего в этом нуждается. Для обеспечения вытеснения 5 на уровне прерываний структура обслуживания прерываний (в том числе и аппаратная архитектура) должна быть многоуровневой. Требование 2: Должно существовать понятие приоритета нити (зада- чи). Как найти нить (задачу), которая нуждается в ресурсах больше всего? В идеальном случае ОСРВ предоставляет ресурсы той задаче или драйверу, у которых осталось меньше всего времени до истечения срока реакции на со- бытие (назовем такую ОС – ОС управляющей критическими сроками). Одна- ко для реализации этого механизма нужно уметь прогнозировать, сколько времени понадобится задаче для завершения своей работы и сколько времени понадобится другим задачам для того, чтобы они успели к своим крити- ческим срокам. Подобная ОСРВ пока еще не создана из-за сложности реализации. Поэтому разработчики ОС используют другой метод: они вводят концепцию приоритетов для нитей (задач). При построении конкретной системы реального времени разработчик должен выстроить приоритеты задач таким образом, чтобы каждая из них успела с реакцией к своему критическому сроку, то есть он должен транс- формировать базовое требование реального времени "успеть с реакцией к нужному моменту" в комбинацию приоритетов и в сценарий их динамиче- ского изменения. Очевидно, что при этой трансформации возможны ошибки, приводящие к неправильной работе системы. Для решения этого вопроса ис- пользуют различные теории, такие как, теорию монотонного планирования или различные методы и средства моделирования. Однако, эти методы ока- зываются не всегда эффективными. Как бы то ни было, во всех современных ОСРВ приходится использовать механизм приоритетов как один из инстру- ментов предсказуемости поведения системы. На сегодяшний день не имеется другого решения, понятие приоритета потока для систем реального времени неизбежно. Требование 3: ОС должна поддерживать предсказуемые механизмы синхронизации нитей (задач). Все нити (задачи) разделяют данные (ресурсы) и должны обмениваться между собой информацией, поэтому необходимы механизмы межзадачного (межнитиевого) взаимодействия. Требование 4: Должен существовать механизм наследования приори- тетов (система должна быть защищена от инверсии приоритетов). Под ин- версией приоритетов будем понимать изменение их обычного порядка. На самом деле именно эти механизмы синхронизации и тот факт, что разные нити выполняются в одном и том же пространстве памяти, и определяют различие между нитями и процессами. Процессы не разделяют одно и то же пространство памяти. Комбинации приоритетов нитей и разделение между ними ресурсов приводит к классической проблеме инверсии приоритетов. Для создания ус- ловия инверсии приоритетов должно быть задействовано как минимум три нити. Если нить с самым низким приоритетом заблокировала ресурс (кото- рый она делит с самой высокоприоритетной нитью), в то время как работает нить с промежуточным приоритетом, возникает следующий эффект: нить с наивысшим приоритетом ожидает освобождения ресурса; нить с промежу- 6 точным приоритетом вытесняет низкоприоритетную нить и работает, пока не завершится; управление получает низкоприоритетная нить, которая освобо- ждает ресурс, и только после этого нить с высоким приоритетом может про- должить свою работу. В этом случае время, необходимое для завершения ни- ти с наивысшим приоритетом, зависит от времени работы нити с более низ- ким приоритетом – это и есть инверсия приоритетов. Очевидно, что в такой ситуации высокоприоритетная нить может "прозевать" критическое событие. Чтобы избежать таких ситуаций, ОСРВ должна быть снабжена меха- низмом наследования приоритетов, то есть блокирующая нить должна на- следовать приоритет нити, которую она блокирует (конечно, только, в том случае, если заблокированная нить имеет более высокий приоритет). Поведение ОС должно быть предсказуемо. Наследование означает, что бло- кирующий ресурс тред наследует приоритет треда, который он блокирует (это справедливо лишь в том случае, если блокируемый тред имеет более высокий приоритет). Здесь есть еще одна проблема: количество возможных приоритетов очень мало. Большинство современных ОСРВ допускают использование как минимум 256 приоритетов. В чем суть проблемы? Ответ очевиден: чем боль- ше приоритетов в распоряжении проектировщика, тем более предсказуемую систему можно создать. При оптимальном проектировании системы различ- ным нитям присваиваются различные приоритеты. Рассмотрим временные требования к операционным системам. Разра- ботчик должен знать все времена выполнения системных вызовов и уметь предсказывать поведение системы в любых ситуациях. Поэтому производи- тель ОСРВ обязательно должен давать информацию о следующих временных характеристиках системы: . задержке прерывания (interrupt latency) - то есть время от момента появления запроса на прерывание до начала его обработки; . максимальном времени исполнения каждого системного вызова. Оно должно быть предсказуемым и не зависеть от количества объектов в системе; . максимальном времени, на которое ОС и драйверы могут блокиро- вать прерывания. Разработчик также должен знать и учитывать следующее: . уровни системных прерываний; . уровни прерываний устройств, максимальное время, которое зани- мают программы обработки прерываний, и т.д. Если все перечисленные выше времена известны, то имеются все предпосылки для создания системы жесткого реального времени. При этом требования к производительности разрабатываемой системы должны быть согласованы с характеристиками выбранной ОСРВ и аппаратуры. Те места в программах, в которых происходит обращение к критиче- ским ресурсам, называются критическими секциями. Решение этой проблемы заключается в организации такого доступа к критическому ресурсу, когда только одному процессу разрешается входить в критическую секцию. 7 Ресурсы, которые не допускают одновременного использования не- сколькими процессами, называются критическими. Если нескольким вычис- лительным ресурсам необходимо пользоваться критическим ресурсом в ре- жиме разделения, им следует синхронизировать свои действия таким обра- зом, чтобы ресурс всегда находился в распоряжении не более чем одного из процессов. Любая система реального времени взаимодействует с внешним миром через аппаратуру компьютера. Внешние события преобразуются в прерыва- ния и обрабатываются драйвером устройства. Доступ к аппаратуре имеют только драйверы. Поскольку приложения реального времени часто работают со специфическими внешними устройст- вами, требующими и специфического управления, разработчик системы ре- ального времени должен уметь разрабатывать драйверы устройств. В ОСРВ разработчик в первую очередь узнает, на каких приоритетах работают драйверы других устройств. Здесь обычно существует свободное пространство для прерываний с приоритетами, которые выше приоритетов стандартных драйверов. Требование 5: Политика управления памятью в ОСРВ. При проекти- ровании системы реального времени необходимо рассмотреть и другой важный вопрос: как строится политика управления памятью в ОСРВ? От решения этой проблемы во многом зависит быстродействие проектируемой системы. Требования, накладываемые на вычислительную установку реального времени, формулируются следующим образом: 1. В зависимости от сложности программы управления, требование «реального времени» накладывает различные условия на вычислительную мощность процессора для СРВ. 2. Внешние события становятся известны системе посредством преры- ваний (interrupt requests (IRQ)) (т.е. запросов на обслуживание со стороны внешних устройств). Поэтому часто для ОСРВ более важна не мощность процессора, а характеристики компьютера, связанные с подсистемой преры- ваний. Желательными являются: - наличие как можно большего количества уровней прерываний (IRQ levels) (т.е. аппаратного или/и программного декодирования источника за- проса); - как можно меньшее время реакции на прерывание (т.е. как можно меньшее время между поступлением запроса на обслуживание и началом выполнения обслуживающей программы). 3. СРВ часто сама является инициатором периодических процессов, которыми управляет (например, движением космического аппарата или луча радара). Поэтому необходимо иметь в наличии один или несколько таймеров (аппаратных устройств, выдающих прерывание через заданные промежутки времени), которые могут работать в периодическом или ждущем режиме. 8 4. Ввиду того, что СРВ часто управляет ответственными промышлен- ными процессами, данное обстоятельство выдвигает очень жесткие требова- ния к надежности используемого оборудования. В течение длительного времени основными потребителями СРВ были военная и космическая области. Сейчас ситуация кардинально изменилась и СРВ можно встретить даже в товарах широкого потребления. Рассмотрим основные области применения СРВ. 3. Основные области применения систем реального времени Военная и космическая области: - бортовое и встраиваемое оборудование; - системы измерения и управления, радары; - цифровые видеосистемы, симуляторы; - ракеты, системы определения положения и привязки к местности. Промышленность: - автоматические системы управления производством (АСУП), автоматические системы управления технологическим процессом (АСУТП); - автомобилестроение: симуляторы, системы управления двигателем, автоматическое сцепление, системы антиблокировки колес и т.д.; - энергетика: сбор информации, управление данными и оборудовани- ем; - телекоммуникации: коммуникационное оборудование, сетевые ком- мутаторы, телефонные станции и т.д.; - банковское оборудование (например, во многих банкоматах работает СРВ QNX). Товары широкого потребления: - мобильные телефоны (например, в телефонах стандарта GSM работает СРВ pSOS); - цифровые телевизионные декодеры; - цифровое телевидение (мультимедиа, видеосерверы); - компьютерное и офисное оборудование (принтеры, копиры), напри- мер, в факсах применяется СРВ VxWorks, в устройствах чтения компакт- дисков – СРВ VRTX32. 4. Аппаратурная среда систем реального времени Систему реального времени можно разделить как бы на три слоя: 1. |