Содержание:
Общее описание операционных систем реального времени
Главная > Реферат >Информатика
1.1 Что такое система реального времени 2
1.2 Основные требования к СРВ 3
1.3 Общие характеристики СРВ 4
1.4 Способы использования ОС 4
1.5 Требования, предъявляемые ОС при проектировании ОСРВ 4
1.5.1 Требование 1. ОС должна быть многонитевой (multi-threaded) и прерываемой 4
1.5.2 Требование 2. Должно существовать понятие приоритета нити 5
1.5.3 Требование 3. ОС должна обеспечивать предсказуемые механизмы синхронизации задач 5
1.5.4 Требование 4. Должна существовать система наследования приоритетов 5
1.5.5 Требование 5. Поведение ОС должно быть известно 5
2. Обзор операционных систем реального времени 6
2.1.1 Профессиональный пакет 7
2.1.2 Рабочая станция 8
2.2 VxWorks/Tornado 9
2.2.1 Базовые сетевые средства VxWorks: UNIX-networking, SNMP и STREAMS. 10
2.2.2 Мониторинг и отладка в реальном масштабе времени: WindView. 10
2.3.1 Основные сложности при реализации систем реального времени в среде LINUX 11
2.3.2 Организация RTLinux 12
2.4 Контроль и управление в реальном времени с использованием OS9 13
2.4.1 Введение 13
2.4.2 Как развивалась эта прикладная система? 14
2.4.3 Утилиты WINOTOOLS: 15
2.5 Windows NT 15
2.5.1 Возможность использования Windows NT в качестве ОС реального времени 15
2.5.2 RTX — real-time extension для Windows NT от компании VenturCom 15
2.5.3 Windows NT 4.0 как ОСРВ. Общие требования 16
2.5.4 Расширения реального времени для Windows NT. Расширение функциональности 16
2.5.4.1 Подсистема реального времени RTSS 17
2.5.4.2 HAL реального времени 17
2.5.4.3 Программный интерфейс реального времени RTAPI 17
3. Литература 18
1. Общее описание операционных систем реального времени
Основой любого аппаратно-программного комплекса, в том числе работающего в режиме реального времени, является операционная система (ОС). Операционной системой называют комплекс программ, обеспечивающий управление ресурсами аппаратно-программного комплекса (вычислительной системы) и процессами, использующими эти ресурсы при вычислениях. Ресурсом в данном контексте является любой логический или физический (и в совокупности) компонент вычислительной системы или аппаратно-программного комплекса и предоставляемые им возможности.
Основными ресурсами являются процессор (процессорное время), оперативная память и периферийные устройства.
Управление ресурсами сводится к выполнению следующих задач: упрощение доступа к ресурсам, распределение их между процессами.
Решение первой задачи позволяет «спрятать» аппаратные особенности вычислительной системы, и тем самым предоставить в распоряжение пользователю или программисту виртуальную машину с существенно облегченным управлением. Таким образом, ОС поддерживает следующие интерфейсы: пользовательский (командный язык для управления функционированием системы и набор сервисных услуг); программный (набор услуг, освобождающий программиста от кодирования рутинных операций).Функция распределения ресурсов является одной из наиболее важных задач, решаемых ОС, однако она присуща не всем ОС, а только тем, которые обеспечивают одновременное выполнение нескольких программ (процессов).
Процессом называется последовательность действий, предписанных программой или ее логически законченной частью, а также данные, используемые при вычислениях. Процесс является минимальной единицей работы, для которой выделяются ресурсы.
В настоящее время существует большое разнообразие ОС, которые классифицируются по следующим признакам:
количество пользователей, одновременно обслуживаемых системой;
число процессов, которые могут одновременно выполняться под управлением ОС;
тип доступа пользователя к системе;
тип аппаратно-программного комплекса.
В соответствии с первым признаком различаются одно- и многопользовательские ОС.
Второй признак делит ОС на одно- и многозадачные.
В соответствии с третьим признаком ОС делятся на:
системы с пакетной обработкой. В этом случае из программ, подлежащих выполнению, формируется пакет, который предъявляется системе для обработки. В этом случае пользователи непосредственно с ОС не взаимодействуют;
системы разделения времени, обеспечивающие одновременный интерактивный доступ к вычислительной системе нескольких пользователей через терминалы. При этом ресурсы системы выделяются каждому пользователю «по очереди», в соответствии с той или иной дисциплиной обслуживания;
системы реального времени, которые должны обеспечивать гарантированное время ответа на внешние события (более подробно см. ниже).
Четвертый признак делит ОС на одно- и многопроцессорные, сетевые и распределенные. Для многопользовательских и многозадачных ОС важным показателем является дисциплина обслуживания. В соответствии с этим различают вытесняющий и согласующий режимы многозадачной работы. При вытесняющей организации выделением задачам процессорного времени занимается только ОС (например, для каждой задачи процессор выделяется по очереди, причем на строго фиксированный промежуток времени, но возможно и приоритетное обслуживание). В случае согласующей организации каждая задача, получив управление, сама определяет, когда ей «отдать» процессор другой задаче. В общем случае согласование эффективнее и надежнее вытеснения, но определяющим фактором при реализации программ становится тот факт, что данная программа не должна монопольно использовать процессорное время.
Система реального времени (СРВ) — это система, правильность функционирования которой зависит не только от логической корректности вычислений, но и от времени, за которое эти вычисления производятся.
Для событий, происходящих в такой системе, важно время, когда эти события происходят, и их логическая корректность. Система работает в реальном времени, если ее быстродействие адекватно скорости протекания физических процессов на объектах контроля или управления (имеются в виду процессы, непосредственно связанные с функциями, выполняемыми конкретной системой реального времени). Система управления должна собрать данные, произвести их обработку по заданным алгоритмам и выдать управляющее воздействие за такой промежуток времени, который обеспечивает успешное выполнение поставленных задач.
1.1 Что такое система реального времени
В последнее время все чаще приходится сталкиваться с задачами, требующими управления сложными процессами или оборудованием при помощи ЭВМ. При этом все события в этих процессах происходят тогда, когда они происходят. Компьютер же может выполнять лишь конечное число операций в конечное время, поэтому возникает вопрос: а успеет ли компьютер с нужной скоростью обсчитать ситуацию и выдать конкретные управляющие действия, которые были бы адекватны именно в определенный момент времени. На мой взгляд, проблемы подобного рода возникли из-за использования очень больших скоростей в современном производстве. Ясно, что сигналы в природе распространяются с конечной скоростью, скорость работы тоже конечна, поэтому мгновенных действий (вызванных неким событием) от компьютера ожидать принципиально невозможно. Ведь каким бы современным (читай — мощным по производительности, т.е. высокой скоростью обработки команд и операций) компьютер бы ни был — ему физически нужны хотя бы доли секунды, чтобы выполнить небольшую простую группу команд, а иногда этого времени слишком много. Таким образом, время реакции системы на некоторое событие строго больше нуля. Реальные задачи допускают некоторого запаздывания действий, и если система имеет время реакции меньше, чем эта допустимая задержка, то ее справедливо называть системой реального времени. Так как в природе разные процессы протекают с разной скоростью, одна и таже система может укладываться в заданные рамки для одного процесса и не укладываться для другого. Таким образом, о системе реального времени имеет смысл говорить применительно к конкретной задаче. Например, чтобы построить зависимость средней температуры воздуха за день от дня недели в качестве системы реального времени сойдет практически любой компьютер с практически любым ПО. Если же мы управляем посадкой самолета, где существенную роль играют миллисекунды, было бы более правильно внимательно выбирать аппаратное и программное обеспечение.
Кроме рассмотренной задачи реагирования на некоторое событие, существуют еще другие классы задач реального времени. Одной из часто встречаемых является задача постоянного наблюдения или управления динамическим процессом, т.е. когда требуется непрерывно обмениваться сигналами с внешним миром. Компьютер — дискретная система, поэтому приходится осуществлять некоторые действия с некоторыми конечными промежутками времени, считая, что в эти малые промежутки времени внешний мир остается неизменным. Если наша система способна обрабатывать информацию и выдавать управляющие сигналы с требуемой частотой, то ее можно назвать системой реального времени. Нетрудно понять, что эту задачу легко свести к предыдущей, используя в качестве события начало очередного интервала времени. Время реакции должно быть меньше времени дискретизации процесса. Таким образом, описанная ранее задача является наиболее важной, когда речь идет о системах реального времени. Следует отметить, что неудовлетворительная по запаздыванию работа системы в некоторых задачах может привести к фатальным последствиям, а в некоторых не произойдет никаких внештатных и нежелательных ситуаций. Например: если система измерения температуры из описанного выше примера случайно опоздает на непозволительное время, то это значит, что мы просто изменили выборку точек съема температуры, и все равно получим правильный результат, если же на секунду случайно задержится автомат захода на посадку в пассажирском самолете при внезапном порыве ветра, самолет может не попасть на полосу и десятки людей погибнут. Таким образом, следует делить системы на системы жесткого и мягкого реального времени.
Системой жесткого реального времени называется система, где неспособность обеспечить реакцию на какие-либо события в заданное время является отказом и ведет к невозможности решения поставленной задачи. Время реакции в системах жесткого реального времени должно быть минимальным. Большинство систем жесткого реального времени являются системами контроля и управления. Такие СРВ сложны в реализации, так как к ним предъявляются особые требования в вопросах безопасности.
Точного определения мягкого реального времени не существует, поэтому можно отнести сюда все СРВ, не подпадающие под категорию жестких. Так, система мягкого реального времени может не успевать все делать в заданное время, поэтому возникает проблема определения критериев успешности (нормальности) ее функционирования.
Кроме того, СРВ можно разделить на системы специализированные и универсальные.
Специализированная СРВ — система, где конкретные временные требования изначально определены. Такая система должна быть специально спроектирована для удовлетворения этих требований.
Универсальная СРВ должна уметь выполнять произвольные (заранее неопределенные) временные задачи без применения специальной техники. Разработка таких систем является самой сложной задачей, хотя обычно, требования, предъявляемые к таким системам, мягче, чем требования к специализированным системам.
Для того, чтобы оценить ресурс, необходимо авторизоваться.
Учебное пособие подготовлено на кафедре «Системы автоматизированного проектирования» Пензенского государственного университета. Предназначено для студентов специальностей 230104 «Системы автоматизированного проектирования» и 230102 «Автоматизированные системы обработки информации и управления» направления 230100 «Информатика и вычислительная техника», а также для специальности 010503 «Математическое обеспечение и администрирование информационных систем». Рассматриваются особенности операционных систем реального времени (ОСРВ), основные определения и положения, стандарты, параметры ОСРВ, требования, предъявляемые к ОС при проектировании систем реального времени, типы архитектур ОСРВ, дается обзор ОСРВ.
Требования к операционной системе реального времени
Требования к операционным системам реального времени
Горбунов Владимир Владимирович,
аспирант Пензенского государственного университета.
В системах реального времени (СРВ), в которых главным критерием эффективности является обеспечение временных характеристик вычислительного процесса, планирование имеет особое значение. Специфика процесса планирования, определяется требованием своевременного выполнения прикладных задач. По мере расширения практики применения СРВ, расширялся и совершенствовался состав методов организации вычислений. В частности, расширялся состав, и повышалась эффективность используемых методов планирования выполнения задач.
Основная задача системы реального времени — получение правильных результатов за определенный крайний срок. Следовательно, вычислительная правильность системы зависит от двух составляющих: логической правильности результатов, и правильности выбора времени[2].
Система реального времени должна давать отклик на любые непредсказуемые внешние воздействия в течение предсказуемого интервала времени.
Для этого должны выполняться следующие требования.
• Ограничение времени отклика. После наступления события реакция на него гарантированно должна последовать до предустановленного крайнего срока. Отсутствие такого ограничения рассматривается как серьезный недостаток программного обеспечения.
• Одновременность обработки. Даже если наступает более одного события одновременно, все временные ограничения для всех событий должны быть выдержаны.
Это означает, что системе реального времени должен быть присущ параллелизм, что достигается использованием нескольких процессоров или многозадачного подхода[1].
Основные требования к операционным системам реального времени.
Мультипрограммность и мультизадачность.
Требование 1. Операционная система должна быть мультипрограммной и мультизадачной (многопоточной — multi-threaded), а также активно использовать прерывания для диспетчеризации.
Максимальное время выполнения того или иного действия в ОСРВ должно быть известно заранее и соответствовать требованиям приложения.
Операционная система так же должна быть многопоточной на принципе абсолютного приоритета (прерываемой). То есть планировщик должен иметь возможность прервать любой поток выполнения и предоставить ресурс тому потоку, которому он более необходим. Операционная система (и аппаратура) должна также обеспечивать прерывания на уровне обработки прерываний.
Требование 2. В системе реального времени должны существовать гарантии того, что событие с высоким приоритетом будет обработано перед событием более низкого приоритета.
ОСРВ должна обладать развитой системой приоритетов. Во-первых, это требуется потому, что система сама может рассматриваться как набор приложений, подразделяющихся на потоки, и несколько высоких уровней приоритетов должны быть выделены системным процессам и потокам. Во-вторых, в сложных приложениях необходимо все потоки реального времени помещать на разные приоритетные уровни, а потоки не реального времени помещать на один уровень (ниже, чем любые потоки реального времени). При этом потоки не реального времени можно обрабатывать в режиме циклического планирования при котором каждому процессу предоставляется квант времени процессора, а когда квант заканчивается, контекст процесса сохраняется, и он ставится в конец очереди. Во многих ОСРВ для планирования задач на одном уровне используется режим циклического планирования.
Требование 3. Должна существовать система наследования приоритетов.
Комбинация приоритетов потоков и разделение ресурсов между ними приводит к проблеме инверсии приоритетов. Это можно проиллюстрировать на примере, где есть как минимум три потока. Когда поток низшего приоритета захватил ресурс, разделяемый с потоком высшего приоритета, и начал выполняться поток среднего приоритета, выполнение потока высшего приоритета будет приостановлено, пока не освободится ресурс и не отработает поток среднего приоритета. В этой ситуации время, необходимое для завершения потока высшего приоритета, зависит от нижних уровней приоритетов — это и есть инверсия приоритетов. В такой ситуации трудно выдержать ограничение на время исполнения.
Чтобы устранить такие инверсии, ОСРВ должна допускать наследование приоритета, то есть повышение уровня приоритета потока до уровня потока, который его вызывает. Наследование означает, что блокирующий ресурс поток наследует приоритет потока, который он блокирует, но это справедливо только в случае, когда блокируемый поток имеет более высокий приоритет.
Синхронизация процессов и задач.
Требование 4. Операционная система должна обеспечивать мощные, надежные и удобные механизмы синхронизации задач. Так как задачи разделяют данные (ресурсы) и должны сообщаться друг с другом, представляется логичным существование механизмов блокирования и коммуникации. То есть необходимы механизмы, гарантированно предоставляющие возможность оперативно обменяться сообщениями и синхросигналами между параллельно выполняющимися задачами и процессами. Эти системные механизмы должны быть всегда доступны процессам, требующим реального времени. Следовательно, системные ресурсы для их функционирования должны быть распределены заранее. Пренебрежение вопросами синхронизации процессов, выполняющихся в режиме мультипрограммирования, может привести к их неправильной работе или даже к краху системы.
Требование 5. Поведение операционной системы должно быть известно и достаточно точно прогнозируемо. Время выполнения системных вызовов и временные характеристики поведения системы в различных обстоятельствах должны быть известны разработчику. Поэтому создатель ОСРВ должен приводить следующие характеристики:
• задержку прерывания, то есть время от момента прерывания до момента запуска задачи: она должна быть предсказуема и согласована с требованиями приложения;
• максимальное время выполнения каждого системного вызова (оно должно быть предсказуемо и не должно зависеть от числа объектов в системе)[1].
1. Гордеев А.В. Операционные системы. 2-е изд. / СПб.: Питер, 2004. – 415с.: ил.
2. Бурдонов И. Б., Косачев А. С., Пономаренко В. Н. Операционные системы реального времени/ Институт системного программирования РАН, 2006. – 98с.: ил.
Поступила в редакцию 14.09.2012 г.
Требования к операционной системе реального времени
Операционные системы реального времени (ОСРВ) предназначены для обеспечения интерфейса к ресурсам критических по времени систем реального времени. Основной задачей в таких системах является своевременность (timeliness) выполнения обработки данных.
В качестве основного требования к ОСРВ выдвигается требование обеспечения предсказуемости или детерминированности поведения системы в наихудших внешних условиях, что резко отличается от требований к производительности и быстродействию универсальных ОС. Хорошая ОСРВ имеет предсказуемое поведение при всех сценариях системной загрузки (одновременные прерывания и выполнение потоков).
Существует некое различие между системами реального времени и встроенными системами. От встроенной системы не всегда требуется, чтобы она имела предсказуемое поведение, и в таком случае она не является системой реального времени. Однако даже беглый взгляд на возможные встроенные системы позволяет утверждать, что большинство встроенных систем нуждается в предсказуемом поведении, по крайней мере, для некоторой функциональности, и таким образом, эти системы можно отнести к системам реального времени.
Принято различать системы мягкого (soft) и жесткого (hard) реального времени. В системах жесткого реального времени неспособность обеспечить реакцию на какие-либо события в заданное время ведет к отказам и невозможности выполнения поставленной задачи. В большинстве русскоязычной литературы такие системы называют системами с детерминированным временем. При практическом применении время реакции должно быть минимальным. Системами мягкого реального времени называются системы, не попадающие под определение «жесткие», т.к. в литературе четкого определения для них пока нет. Системы мягкого реального времени могут не успевать решать задачу, но это не приводит к отказу системы в целом. В системах реального времени необходимо введение некоторого директивного срока (в англоязычной литературе – deadline), до истечения которого задача должна обязательно (для систем мягкого реального времени – желательно) выполниться. Этот директивный срок используется планировщиком задач как для назначения приоритета задачи при ее запуске, так и при выборе задачи на выполнение.
Мартин Тиммерман сформулировал следующие необходимые требования для ОСРВ [DEDSYS]:
- ОС должна быть многозадачной и допускающей вытеснение (preemptable),
- ОС должна обладать понятием приоритета для потоков,
- ОС должна поддерживать предсказуемые механизмы синхронизации,
- ОС должна обеспечивать механизм наследования приоритетов,
- поведение ОС должно быть известным и предсказуемым (задержки обработки прерываний, задержки переключения задач, задержки драйверов и т.д.); это значит, что во всех сценариях рабочей нагрузки системы должно быть определено максимальное время отклика.
В течение последних 25-30 лет структура операционных систем эволюционировала от монолитной к многослойной структуре ОС и далее к архитектуре клиент-сервер. При монолитной структуре ОС состоит из набора модулей, и изменения одного модуля влияют на другие модули. Чем больше модулей, тем больше хаоса при эксплуатации такой системы. Кроме того, невозможно распределить ОС в многопроцессорной системе. В многослойной структуре изменения одного слоя влияют на соседние слои; кроме того, обращение через слой невозможно. Для систем реального времени должно быть обеспечено прямое обращение к каждому слою ОС, а иногда напрямую к аппаратуре.
Основной идеей клиент-серверной технологии в ОС является сведение базиса ОС к минимуму (планировщик и примитивы синхронизации). Вся остальная функциональность выносится на другой уровень и реализуется через потоки или задачи. Совокупность таких серверных задач отвечает за системные вызовы. Приложения являются клиентами, которые запрашивают сервисы через системные вызовы.
Клиент-серверная технология позволяет создавать масштабируемые ОС и упрощает распределение в многопроцессорной системе. При эксплуатации системы замена одного модуля не вызывает эффекта “снежного кома”; кроме того, сбой модуля не всегда влечет за собой отказ системы в целом. Появилась возможность динамической загрузки и отгрузки модулей. Главной проблемой в этой модели является защита памяти, поскольку серверные процессы должны быть защищены. При каждом запросе сервиса система должна переключаться с контекста приложения на контекст сервера. При поддержке защиты памяти время переключения с одного процесса на другой увеличивается.
Как правило, большинство современных ОСРВ построено на основе микроядра (kernel или nucleus), которое обеспечивает планирование и диспетчеризацию задач, а также осуществляет их взаимодействие. Несмотря на сведение к минимуму в ядре абстракций ОС, микроядро все же должно иметь представление об абстракции процесса. Все остальные концептуальные абстракции операционных систем вынесены за пределы ядра, вызываются по запросу и выполняются как приложения.
Рассмотрим концептуальные абстракции операционной системы через призму требований к системам реального времени.
ОПЕРАЦИОННЫЕ СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ
40. Основные принципы построения операционных систем
Архитектура системы — ее структура и основные принципы построения.
Основные принципы построения ОС:
1. Принцип модульности
? ОС строится из множества программных модулей. Под модулем в общем случае понимают функционально законченный элемент системы, выполненный в соответствии с принятыми межмодульными интерфейсами. Модуль может быть легко заменен другим при наличии заданных интерфейсов.
? Особо важное значение имеют привилегированные, повторно входимые и реентерабельные модули.
Во всех операционных системах можно выделить:
1) часть наиболее важных управляющих модулей, которые должны постоянно находиться в оперативной памяти вместе с некоторыми системными структурами данных, необходимыми для функционирования операционной системы, они образуют ядро операционной системы. В его состав, как правило, входят модули по управлению системой прерываний, средства по переводу программ из состояния счета в состояние ожидания, готовности и обратно, средства по распределению основных ресурсов, таких как оперативная память и процессор;
2)много других системных программных модулей, которые называют транзитными (диск-резидентными). Загружаются в оперативную память только при необходимости и в случае отсутствия свободного пространства могут быть замещены другими транзитными модулями.
2. Принцип особого режима работы Ядро операционной системы и низкоуровневые драйверы, управляющие работой каналов и устройств ввода-вывода, должны работать в специальном режиме работы процессора (привилегированном).
Это необходимо по причинам:
1) позволяет существенно повысить надежность выполнения вычислений.
2) ряд функций должен выполняться централизованно, под управлением операционной системы (прежде всего, функции, связанные с управлением процессами ввода-вывода данных).
3. Принцип виртуализации
Сейчас используется практически в любой операционной системе.
Виртуализация ресурсов позволяет:
? организовать разделение тех ресурсов между вычислительными процессами, которые не должны разделяться;
? абстрагироваться от конкретных ресурсов, обобщить их свойства и работать с некоторой абстракцией.
Проявления концепции виртуальности:
1) понятие виртуальной машины. Любая операционная система скрывает от пользователя и его приложений реальные аппаратные и иные ресурсы, заменяя их некоторой абстракцией. В результате пользователи видят и используют виртуальную машину в составе:
? единообразная по логике работы память достаточного для выполнения приложений объема.
? произвольное количество процессоров, способных работать параллельно и взаимодействовать во время работы.
? произвольное количество внешних устройств, способных работать с памятью виртуальной машины параллельно или последовательно, асинхронно или синхронно по отношению к работе того или иного виртуального процессора, которые инициируют работу этих устройств.
2) возможность организации выполнения в операционной системе приложений, разработанных для другой операционной системы, имеющей совсем другой интерфейс прикладного программирования. Т.е. организация нескольких операционных сред;
3) независимость программ от внешних устройств – связь программ с конкретными устройствами производится не в процессе создания программы, а в период планирования ее исполнения. Этот принцип позволяет одинаково осуществлять операции управления внешними устройствами независимо от их конкретных физических характеристик.
4. Принцип мобильности
Мобильность, или переносимость, означает возможность и легкость переноса операционной системы на другую аппаратную платформу. Мобильная операционная система обычно разрабатывается с помощью специального языка высокого уровня, предназначенного для создания системного программного обеспечения. Одним из таких языков является язык С, а также C++ .
1) архитектуры разных процессоров могут сильно различаться.
2) для ОС важной является не только архитектура центрального процессора, но и архитектура компьютера в целом.
? Для обеспечения мобильности был создан стандарт на интерфейс прикладного программирования, названный POSIX (Portable Operating System Interface for Computer Environments — интерфейс прикладного программирования для переносимых операционных систем). ? Платой за универсальность, прежде всего, является потеря производительности, поэтому ряд разработчиков идут на отказ от принципа мобильности, поскольку не всегда следование этому принципу экономически оправдано.
5. Принцип совместимости
? Одним из аспектов совместимости – способность операционной системы выполнять программы, написанные для других систем или для более ранних версий данной операционной системы, а также для другой аппаратной платформы.
? Необходимо разделять вопросы двоичной совместимости и совместимости на уровне исходных текстов приложений.
? Двоичная совместимость достигается в том случае, когда можно взять исполняемую программу и запустить ее на выполнение на другой операционной системе.
? Совместимость на уровне исходных текстов требует наличия соответствующего транслятора в составе системного программного обеспечения, а также совместимости на уровне библиотек и системных вызовов.
? Гораздо сложнее достичь двоичной совместимости между процессорами, основанными на разных архитектурах. Для того чтобы один компьютер выполнял программы другого, он должен работать с машинными командами, которые ему изначально непонятны. Выходом является использование так называемых прикладных сред, или эмуляторов.
? Поскольку основную часть программы, как правило, составляют вызовы библиотечных функций, прикладная среда имитирует библиотечные функции целиком, используя заранее написанную библиотеку функций аналогичного назначения, а остальные команды эмулирует каждую по отдельности.
6. Принцип генерируемоемости
? Исходное представление центральной системной управляющей части операционной системы должно обеспечивать возможность настройки, исходя из конкретной конфигурации конкретного вычислительного комплекса и круга решаемых задач.
? Под генерацией операционной системы понимается ее сборка (компоновка) из отдельных программных модулей. В результате генерации получают скомпонованные двоичные коды операционной системы и построенные системные таблицы, отражающие конкретную конфигурацию компьютера.
? Процесс генерации осуществляется с помощью специальной программы-генератора и соответствующего входного языка для этой программы. В результате генерации получается полная версия операционной системы.
7. Принцип открытости
? Открытая операционная система доступна для анализа как пользователям, так и системным специалистам, обслуживающим вычислительную систему. Необходимо, чтобы можно было легко внести дополнения и изменения, если это потребуется, не нарушая целостности системы.
? Этот принцип иногда трактуют как расширяемость системы.
? К открытым операционным системам прежде всего следует отнести UNIX-системы.
8. Принцип обеспечения безопасности вычислений
? Правила безопасности определяют свойства:
— защита ресурсов одного пользователя от других,
— установление квот по ресурсам для предотвращения захвата одним пользователем всех системных ресурсов. ? Для обеспечения защиты информации от несанкционированного доступа чаще всего используется механизм учетных записей. Он предполагает проведение аутентификации и aвторизации пользователя.
? Во многих современных операционных системах гарантируется степень безопасности данных, соответствующая уровню С2 в системе стандартов США.
? Основы стандартов в области безопасности были заложены «Критериями оценки надежных компьютерных систем» (Оранжевая Книга).
? Иерархия уровней безопасности, приведенная в Оранжевой Книге, помечает низший уровень безопасности как D, а высший – как А:
? В класс D попадают системы, оценка которых выявила их несоответствие требованиям всех других классов.
? Основные свойства С-систем: наличие подсистемы учета событий, связанных с безопасностью, и избирательный контроль доступа.
? Системы уровня В основаны на помеченных данных и распределении пользователей по категориям, то есть реализуют мандатный контроль доступа.
? Уровень А требует в дополнение ко всем требованиям уровня В выполнения доказательства соответствия системы требованиям безопасности.
42. Микроядерные и макроядерные операционные системы
? В микроядерных операционных системах можно выделить центральный компактный модуль, относящийся к супервизорной части системы. Этот модуль имеет очень небольшие размеры и выполняет относительно небольшое количество управляющих функций, но позволяет передать управление на другие управляющие модули, которые и выполнят затребованную функцию.
? Микроядро – это минимальная главная часть операционной системы, служащая основой модульных и переносимых расширений.
? Микроядро само является модулем системного программного обеспечения, работающим в наиболее приоритетном состоянии компьютера и поддерживающим связи с остальной частью операционной системы, которая рассматривается как набор серверных приложений (служб).
? Основная идея технологии микроядра – создать необходимую среду верхнего уровня иерархии, из которой можно легко получить доступ ко всем функциональным возможностям уровня аппаратного обеспечения. При этом микроядро является стартовой точкой для создания всех остальных модулей системы.
? В микроядре содержится и исполняется минимальное количество кода, необходимое для реализации основных системных вызовов.
? Для большинства микроядерных операционных систем основой архитектуры выступает технология микроядра Mach.
? Микроядро обеспечивает только пять типов сервисов:
? управление виртуальной памятью;
? поддержка заданий и потоков;
? взаимодействие между процессами;
? управление поддержкой ввода-вывода и прерываниями;
? сервисы хоста и процессора.
? Наиболее ярким представителем микроядерных операционных систем является ОС реального времени QNX. ? В макроядерных, или монолитных, операционных системах ядро, состоящее из множества управляющих модулей и структур данных, не разделено на центральную часть и периферийные модули. Ядро получается монолитным, неделимым. В этом смысле макроядерные операционные системы являются прямой противоположностью микроядерным.
? Проблемы монолитных операционных систем:
? опасность возникновения конфликта между различными частями ядра;
? сложность подключения к ядру новых драйверов.
? Очень плодотворным оказался подход, основанный на модели клиент-сервер.
? Микроядерные операционные системы в полной мере используют модель клиент-сервер.
? Микроядерные операционные системы сегодня разрабатываются чаще монолитных. Однако использование технологии клиент-сервер — это еще не гарантия того, что операционная система станет микроядерной.
43. Требования к операционным системам реального времени
Требования к системе реального времени (СРВ):
? ограничение времени отклика;
Различают системы «мягкого» и «жесткого» реального времени.
Система считается жесткой, если «нарушение временных ограничений недопустимо», и мягкой, если «нарушение времени ограничений нежелательно».
43.Основные требования к ОСРВ:
1. Мультипрограммность и мультизадачность
ОС должна быть мультипрограммной и мультизадачной, активно использовать прерывания для диспетчеризации, быть предсказуемой. Т.е. ОС должна быть многопоточной на принципе абсолютного приоритета (прерываемой).
2. Приоритеты задач
Должно существовать понятие приоритета потока (задачи). Сложно определить, какой задаче ресурс требуется больше всего. Операционных систем, построенных по этому принципу, практически нет, т.к. он сложен для реализации. Поэтому разработчиками ОС вводится понятие уровня приоритета для задачи, и временные ограничения сводятся к приоритетам.
3. Наследование приоритетов
? Комбинация приоритетов потоков и разделение ресурсов между ними приводит проблеме инверсии приоритетов.
? Время, необходимое для завершения потока высшего приоритета, зависит от нижних уровней приоритетов — это и есть инверсия приоритетов.
? Чтобы устранить такие инверсии, ОСРВ должна допускать наследование, приоритета, то есть повышение уровня приоритета потока до уровня потока, который его вызывает.
4. Сихронизация процессов и задач
ОС должна обеспечивать мощные, надежны удобные механизмы синхронизации задач. Необходимы механизмы, гарантированно предоставляющие возможность оперативно обменяться сообщениями и синхросигналами между параллельно выполняющимися задачами и процессами.
Поведение операционной системы должно быть известно и достаточно точно прогнозируемо. Создатель ОСРВ должен приводить характеристики:
? время от момента прерывания до момента запуска задачи;
? максимальное время выполнения каждого системного вызова;
? максимальное время маскирования прерываний драйверами и супервизорными модулями операционной системы. 44. Интерфейсы операционных систем
? Под интерфейсами операционных систем понимают специальные интерфейсы системного и прикладного программирования (API), предназначенные для выполнения следующих задач.
? запуск, приостанов и снятие задачи с выполнения;
? задание или изменение приоритета задачи;
? взаимодействие задач между собой;
? вызов удаленных процедур (RPC).
? запрос на выделение блока памяти;
? изменение параметров блока памяти;
? отображение файлов на память (имеется не во всех системах).
? запрос на управление виртуальными устройствами;
Интерфейс пользователя с операционной системой реализуется с помощью специальных программных модулей – интерпретаторов команд, которые принимают его команды на соответствующем языке (возможно, с использованием графического интерфейса) и транслируют их в обычные вызовы в соответствии с основным интерфейсом системы.
? Получив от пользователя команду, такой модуль после лексического и синтаксического анализа или сам выполняет действие, или (чаще), обращается к другим модулям ОС, используя механизм API.
? В последние годы большую популярность получили графические интерфейсы (GUI), в которых задействованы соответствующие манипуляторы типа мышь или трекбол. Указание курсором на объект и щелчок или двойной щелчок на соответствующей кнопке мыши приводит к каким-либо действиям. Такая интерфейсная подсистема транслирует «команды» пользователя в обращения к операционной системе.
? Управление GUI является частным случаем задачи управления вводом-выводом и не относится к функциям ядра операционной системы.
? Интерфейс прикладного программирования API разделяют на следующие направления:
? API как интерфейс высокого уровня, принадлежащий к библиотекам RTL;
? API прикладных и системных программ, входящих в поставку операционной системы;
? прочие интерфейсы API.
? Интерфейс прикладного программирования, предназначен для использования прикладными программами системных ресурсов компьютера и реализуемых операционной системой разнообразных системных функций. API описывает совокупность функций и процедур, принадлежащих ядру или надстройкам операционной системы.
? API — это набор функций, предоставляемых системой программирования разработчику прикладной программы и ориентированных на организацию взаимодействия результирующей прикладной программы с целевой вычислительной системой.
? Функции API позволяют разработчику строить результирующую прикладную программу так, чтобы использовать средства целевой вычислительной системы для выполнения типовых операций. При этом разработчик программы избавлен от необходимости создавать исходный код для выполнения этих операций.
? Варианты реализации API:
? реализация на уровне модулей операционной системы;
? реализация на уровне системы программирования;
? реализация на уровне внешней библиотеки процедур и функций.
Интерфейс POSIX ? POSIX— это стандарт, описывающий системные интерфейсы для открытых операционных систем, в том числе оболочки, утилиты и инструментарии.
? Кроме того, согласно POSIX, стандартизированными являются задачи обеспечения безопасности, задачи реального времени, процессы администрирования, сетевые функции и обработка транзакций. Стандарт базируется на UNIX-системах, но допускает реализацию и в других операционных системах.
? Этот стандарт подробно описывает систему виртуальной памяти, многозадачность и технологию переноса операционных систем.
? POSIX представляет собой множество стандартов POSIX.1 – POSIX.12.
ОПЕРАЦИОННЫЕ СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ.
Основные требования, предъявляемые к операционным системам (ОС), используемым в АСУ и СРВ:
• предсказуемость поведения во временной области;
• масштабируемость (т.е. возможность получать сверхкомпактные и сверхбыстрые варианты ОС за счет отключения ряда компонентов и функций).
ОС, удовлетворяющие требованию предсказуемости поведения во временной области, называются операционными системами реального времени (ОС РВ). ОС, удовлетворяющие требованию масштабируемости, называются встраиваемыми операционными системами.
Современные ОС, предназначенные для использования в АСУ и СРВ, обычно удовлетворяют обоим требованиям.
studopedia.org — Студопедия.Орг — 2014-2018 год. Студопедия не является автором материалов, которые размещены. Но предоставляет возможность бесплатного использования (0.009 с) . 