Контрольная работа по "Информатике"

Вопрос №1. Что  относится к системам реального  времени  в настоящее время. Основные требования для таких систем.

ВВЕДЕНИЕ

ОБЩЕЕ ОПИСАНИЕ ОПЕРАЦИОННЫХ СИСТЕМ РЕАЛЬНОГО ВРЕМЕНИ

Определение  

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

Основными ресурсами  являются процессор (процессорное время), оперативная память и периферийные устройства. 

Управление ресурсами  сводится к выполнению следующих  задач: упрощение доступа к ресурсам; распределение их между процессами. 

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

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

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

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

В настоящее  время существует большое разнообразие ОС, которые классифицируются по следующим  признакам: 

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

число процессов, которые могут одновременно выполняться  под управлением ОС; 

тип доступа  пользователя к системе; 

тип аппаратно-программного комплекса. 

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

В соответствии с третьим признаком ОС делятся: 

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

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

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

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

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

Видно, что в  настоящее время существует огромное количество типов ОС, в дальнейшем рассматриваются только операционные системы реального времени (ОСРВ). 

Если рассматривать  ОСРВ, то необходимо определиться с  понятием систем реального времени. 

Система реального  времени (СРВ) – это система, правильность функционирования которой зависит  не только от логической корректности вычислений, но и от времени, за которое  эти вычисления производятся.  

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

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

Основные требования к СРВ: 

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

предсказуемость; 

важно максимальное (не среднее) время отклика на событие; 

особые требования в вопросах безопасности; 

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

Общие характеристики СРВ: 

большие и сложные  системы; 

распределенные  системы; 

жесткое взаимодействие с аппаратурой; 

выполнение задач  зависит от времени; 

сложность тестирования. 

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

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

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

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

Кроме того, СРВ  можно разделить на системы специализированные и универсальные. Специализированная СРВ – система, где конкретные временные требования априори определены. Такая система должна быть специально спроектирована для удовлетворения этих требований. 

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

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

Для более детального рассмотрения возможностей ОСРВ представлены ориентировочные цифры, дающее представление  о порядке времен реакции и  подходящих операционных системах (см. таблицу). Данная таблица сформирована на основании экспериментальных  данных, полученных на базе вычислительных комплексов, построенных на основе процессоров Intel 80486DX. Безусловно, данный процессор на сегодняшний день является устаревшим, но можно сделать выводы об уровне реакции на внешние события раз-личных ОСРВ. 

Время реакции 

Использованные ОС 

Менее 10 мкс 

Только ОСРВ, но даже они могут быть бессильны  – это граница выбора между  схемным и программным решениями 

10 – 100 мкс 

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

100 мкс – 1 мс 

ОСРВ, RTAI, RT LINUX, расширения

 реального  времени для Windows NT, CE 

1 мс 

Можно пытаться делать что-то с Linux и Windows NT, но не для систем, где опоздания

 реакции могут  привести к тяжелым последствиям 
 
 

Таким образом, видно, что временные рамки ОСРВ достаточно жесткие. Среди современных  операционных систем есть класс продуктов, разработанных специально для построения систем жесткого реального времени  – VxWorks, OS9, QNX, LynxOS, OSE и другие. Эти системы содержат необходимый набор инструментов и в некоторых случаях являются единственным выбором – на него приходится идти, невзирая на затраты. Однако достаточно часто требования к реальному времени (полная предсказуемость времени реакции) допускают компромиссы, например, необходимо добиться только нужной средней производительности. 

Иногда достаточно жестко контролировать только одно из событий, допуская при этом задержки реакций на остальные. В подобных случаях возможности выбора расширяются  и желаемых результатов можно  достичь, используя такие широко распространенные операционные системы  как LINUX, Windows NT, Windows CE, дополняя их расширениями реального времени (RTAI, RT LINUX, RTX).

Требования, предъявляемые  ОС при проектировании ОСРВ 

Требование 1. ОС должна быть многонитевой (multi-threaded) и прерываемой 

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

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

Требование 2. Должно существовать понятие приоритета нити 

Проблема в  том, чтобы определить, какой задаче требуется ресурс. В идеальной  ситуации ОСРВ отдает ресурс нити или  драйверу с ближайшим крайним  сроком (так называемые ОС, управляемые  временным ограничением (deadline driven OS)).  

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

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

 синхронизации  задач 

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

Требование 4. Должна существовать система наследования приоритетов 

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

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

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

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

Требование 5. Поведение  ОС должно быть известно 

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

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

максимальное  время выполнения каждого системного вызова (должно быть предсказуемым  и независимым от числа объектов в системе); 

максимальное  время маскирования прерываний драйверами и ОС. 

системные уровни прерываний; 

уровни прерываний драйверов устройств, их временные  характеристики и т. д. 

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

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

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

QNX 

Операционная  система QNX является разработкой канадской  компании QNX Software System Ltd (1981).  

Операционная  система QNX представляет собой гибрид 16/32-битовой операционной системы, которую  пользователь может конфигурировать  по своему усмотрению. Наиболее часто  она применяется для создания систем, работающих в реальном масштабе времени. Время, необходимое для  полной инсталляции системы, включая  сетевые средства, составляет всего 10–15 мин, после чего можно начинать работу. Нетребовательность системы  к ресурсам проявляется уже в  том, что система с необходимой  и достаточной средой разработки в виде компилятора Watcom C/C++ (основной компилятор для QNX) умещается в 10 Мб. 

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

Эти идеи позволили  добиться нескольких важнейших преимуществ: 

предсказуемость, означающую ее применимость к задачам  жесткого реального времени; Ни одна версия UNIX не может достичь подобного  качества, поскольку код ядра слишком  велик. Любой системный вызов  из обработчика прерывания в UNIX может  привести к непредсказуемой задержке (как и Windows NT); 

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

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

Система построена  по технологии FLEET [Fault-tolerance (отказоустойчивая), Load-bаlаncing (регулирующая нагрузку), Еffiсiеnt (эффективная), Ехtеnsible (расширяемая), Тгаnsparent (прозрачная)], которая выражается в следующем. QNX является ОСРВ на основе микроядра (размером около 10 Кб). В качестве основного средства взаимодействия между процессами система использует передачу сообщений. Благодаря этому в 32-битовой среде возможно взаимодействие процессов с 32 и 16-битовыми кодами, причем сообщения передаются между любыми процессами, независимо от того, находятся ли процессы на одном компьютере или на разных узлах сети.  

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

Операционная  система QNX объединяет всю сеть ПК в  единый набор ресурсов с абсолютной прозрачностью доступа к ним. Узлы могут добавляться и исключаться  из сети, не влияя на целостность  системы. Сетевая обработка данных в QNX является настолько гибкой, что  можно объединить в одну сеть любой  разнородный набор Intel совместимых компьютеров, соединенных через Arcnet, Ethernet, Token Ring или через последовательный порт, к которому также может быть подключен модем. Кроме того, возможно участие компьютера одновременно в нескольких сетях, и если одна из них окажется перегруженной или выйдет из строя, то QNX автоматически будет использовать другие доступные сети без потери информации.  

QNX имеет некоторые  ограничения, связанные с ориентацией  системы на рынок встроенных  систем реального времени: 

нет поддержки SMP; 

отсутствует запись виртуальной памяти на диск; 

неэффективная и нестандартная поддержка нитей; 

неполноценная реализация отображения файлов в  память; 

нет поддержки UNIX-domain sockets; 

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

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

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

VxWorks/Tornado 

Операционная  система реального времени VxWorks и инструментальная среда Tornado фирмы Wind River Systems предназначены для разработки ПО встроенных компьютеров, работающих в системах жесткого реального времени. Операционная система VxWorks является системой с кросс-средствами разработки прикладного программного обеспечения, разработка ведется на инструментальном компьютере (host) в среде Tornado для последующего исполнения на целевой машине (target) под управлением VxWorks. 

VxWorks поддерживает целевые архитектуры (targets): 

Motorola 680x0 и CPU32, PowerPC; 

Intel 386/486/Pentium, Intel 960; 

Spare, Mips R3000/4000; 

AMD 29K, Motorola 88110; 

HP PA-RISC; 

Hitachi SH7600; 

DEC Alpha. 

Инструментальные  платформы, поддерживаемые для Tornado (hosts): 

Sun SPARCstation (SunOS и Solaris); 

HP 9000/400,700 (HP-UX); 

IBM RS6000 (AIX); 

Silicon Graphics (IRIX); 

DEC Alpha (OSF/1); 

PC (Windows). 

Поддерживаемые  интерфейсы host-target: 

host-target Ethernet; 

RS232; 

внутрисхемный эмулятор ICE (In-Circuit Emulator); 

кросс-шина (backplane). 

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

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

Все аппаратно-зависимые  части VxWorks вынесены в отдельные модули для того, чтобы разработчик встроенной компьютерной системы мог сам портировать VxWorks на свою нестандартную целевую машину. Этот комплект конфигурационных и инициализационных модулей называется (Board Support Package, BSP) и поставляется для стандартных компьютеров (VME-процессор, PC или Sparcstation) в исходных текстах. Разработчик нестандартной машины может взять за образец BSP наиболее близкий по архитектуре стандартный компьютер и перенести VxWorks на свою машину путем разработки собственного BSP с помощью BSP Porting Kit. 

Базовые сетевые  средства VxWorks: UNIX-networking, SNMP и STREAMS. 

VxWorks была первой операционной системой реального времени, в которой реализован протокол TCP/IP с учетом требований реального времени. С тех пор VxWorks поддерживает все сетевые средства, стандартные для UNIX: TCP/UDP/ICMP/IP/ARP, Sockets, SLIP/CSLIP/PPP, telnet/rlogin/rpc/rsh, ftp/tftp/bootp, NFS (клиент и сервер). 

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

STREAMS – стандартный  интерфейс для подключения переносимых  сетевых протоколов к операционным  системам, реализован в VxWorks как в версии SVR3, так и SVR4. Таким образом, в VxWorks можно инсталлировать любой протокол, имеющий STREAMS-реализацию, как стандартный (Novell IPX/SPX, DECNET, Apple-Talk и пр.), так и специализированный. Wind River Systems анонсировала (1994) программу WindNet, по которой ведущие фирмы-производители программных средств в области коммуникаций интегрировали свои программные продукты с VxWorks.