GRID_УП

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

3.2.3Клиент-серверные ОС (модульная архитектура, архитектура на основемикроядра)

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

Уровень пользователя

Уровень ядра

Микроядро

Рис. 3.8 — Архитектура клиент-серверной ОС

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

–Повышается надежность ОС, т.к. каждый сервис является, по сути, самостоятельным приложением и его легче отладить

иотследить ошибки.

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

–Повышается отказоустойчивость системы, т.к. «зависший» сервис можетбытьперезапущенбезперезагрузкисистемы.

Среди известных ОСРВ, реализующих архитектуру микроядра, можно отметить OS9 и QNX.

Недостатки данной архитектуры те же, что и у монолитной архитектуры. Проблемы перешли с уровня API на уровень микроядра. Системный интерфейс по-прежнему не допускает переключения задач во время работы микроядра, только сократилось время пребывания в этом состоянии. Часть API может также быть реализована на ассемблере. Проблемы переносимости сократились, но остались.

73

3.2.4Объектная архитектура на основе объектовмикроядер

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

Фактическое равноправие всех компонент системы обеспечивает возможность переключения задач в любое время, т.е. система полностью вытесняема в режиме ядра — preemptable.

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

Роль API играет компилятор и динамический редактор объектных связей (linker). При старте приложения динамиче-

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

Основным представителем данной архитектуры является

ОСРВ Soft Kernel.

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

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

74

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

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

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

ввиде специальных модулей, называемых DLL (Dynamically Linked Libraries — динамически связываемые библиотеки). DLL обеспечивает разделение своего кода и данных для всех работающих приложений, в то время как для микроядер можно управлять доступом для каждого конкретного приложения. DLL не поддерживает объектно-ориентированный подход, код DLL не является позиционно-независимым ине можетбытьзаписан вПЗУ.

3.2.5Обобщенное построение ОСРВ

Обобщенное построение операционных систем реального времени можно разделить на три слоя (рис. 3.9):

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

Система

управления

Ядро

Рис. 3.9 — Типичное строение ОСРВ

75

–Ядро — содержит только строгий минимум функций необходимый для работы системы. К минимуму относятся следующие функции:

o управление, синхронизация и взаимодействие задач; o управление памятью;

o управление устройствами ввода-вывода.

–Система управления — содержит ядро и ряд дополнительных сервисов, расширяющих его возможности:

o расширенное управление памятью;

o расширенное управление устройствами ввода-вывода; o расширенное управление задачами;

o управление файлами;

o обеспечение взаимодействия системы и внешнего оборудования и т.д.

–Система реального времени — содержит систему управления и набор утилит: средства разработки, средства визуализации и т.д.

3.3Разделение ОСРВ по способу разработки

Операционные системы реального времени по способу разработки программного обеспечения делят на следующие категории:

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

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

76

ОСРВ не используются и только зря занимают память и другие ресурсы компьютера.

Обычно self-hosted ОСРВ применяются на «обычных» компьютерах промышленного исполнения.

Host/Target ОСРВ — это системы, в которых операционная система и компьютер, на котором разрабатываются приложения (host), и операционная система и компьютер, на котором запускаются приложения (target), различны. Связь между компьютерами осуществляется с помощью последовательно соединения

(COM-порта), Ethernet, общей шины VME или compact PCI. В

качестве host-системы обычно выступает компьютер под управлением Unix или Windows NT, в качестве target-системы выступает промышленный или встраиваемый компьютер под управлением ОСРВ.

Достоинством таких систем является использование всех ресурсов «обычной» системы для создания приложений и уменьшение размеров ОСРВ за счет включения только нужных приложению компонент. Недостатком является относительная сложность программных компонент: кросс-компилятора, удаленного загрузчика и отладчика и т.д.

В настоящее время рост мощности промышленных компьютеров позволяет использовать self-hosted ОСРВ на большем числе вычислительных систем. Хотя, с другой стороны, это увеличивает распространение встраиваемых систем (в разнообразном промышленном и бытовом оборудовании), расширяет сферу применения host/target систем, поскольку при больших объемах выпуска цена системы является определяющим фактором.

Большинство современных ведущих операционных систем реального времени поддерживают целый спектр аппаратных архитектур, на которых работают системы исполнения (Intel, Motorola, RISC,MIPS, PowerPC и другие). Это объясняется тем,

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

77

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

Вопросы для самопроверки

1.Дайтеопределениепонятиюмеханизма диспетчеризации.

2.Расскажите о проблеме разделения ресурсов.

3.В чем отличие понятий процессов от потоков?

4.Какое свойство потока отвечает за предоставление ему процессорного времени?

5.В каких состояниях может находиться поток?

6.Какие методы диспетчеризации Вы знаете?

7.В чем отличие вытесняющей многозадачности от адаптивной и приоритетной?

8.Сколько уровней приоритетов должна иметь операционная система реального времени?

9.Какая серьезная проблема возникает при блокировании ресурсов?

10.Какие механизмы существуют для решения проблемы инверсии приоритетов?

11.Какие требования по временным характеристикам накладываются на системы реального времени?

12.Сформулируйте принципиальные отличия ОСРВ от ОС общего назначения.

13.Перечислите архитектуры построения ОСРВ.

14.Как можно описать обобщенную структуру ОСРВ?

15.В чем отличие категории ОСРВ Self-Hosted от категории

Host/Target?

78

4 СТАНДАРТЫ НА ОСРВ

4.1 Важность стандартов на ОСРВ

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

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

4.2 Стандарт SCEPTRE

Стандарт SCEPTRE (Standardisation du Cœur des Exécutifs des Produits Temps Réel Européens) — европейский стандарт на основы систем реального времени (sceptre по-французски означает «скипетр») разрабатывался в 1980—90 годы. За время его создания появились новые концепции в ОСРВ, не все из которых успели найти отражение в стандарте. В стандарте объединены усилия инженеров и исследователей в разработке групп спецификаций для промышленных приложений, даны определения и описания набора методов и подходов, используемых в ОСРВ.

Стандарт SCEPTRE определяет семь основных целей, которые должны преследовать ОСРВ:

1.Адекватность поставленной задаче.

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

79

3.Минимальная стоимость.

4.Максимальная производительность.

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

6.Адаптивность (способность системы приспосабливаться

кновому управляемому ею оборудованию и задачам).

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

Весь сервис, предоставляемый операционной системой, разделен в стандарте на следующие группы:

–коммуникации (межпроцессорное взаимодействие);

–синхронизация процессов;

–контроль и планирование задач;

–управление памятью;

–управление прерываниями и оборудованием ввода/вывода;

–высокоуровневый интерфейс ввода/вывода и управление периферийными устройствами;

–управление файлами;

–управление транзакциями (сообщениями и передачами данных);

–обработка ошибок и исключений;

–управление временем.

4.3Стандарт POSIX

Наиболее ранним и распространенным стандартом ОСРВ является стандарт POSIX (IEEE Portable Operating System

Interface for Computer Environments, IEEE 1003.1). Первона-

чальный вариант стандарта POSIX появился в 1990 г. и был предназначен для UNIX-систем, первые версии которых появились в 70-х годах прошлого века. Спецификации POSIX определяют стандартный механизм взаимодействия прикладной программы и операционной системы и в настоящее время включают набор более чем из 30 стандартов. Для ОСРВ наиболее важ-

80

ны семь из них (1003.1a, 1003.1b, 1003.1c, 1003.1d, 1003.1j, 1003.21, 1003.2h), но широкую поддержку в коммерческих ОС получили только три первых.

Несмотря на явно устаревшие положения стандарта POSIX и большую потребность в обновлении стандартизации для ОСРВ, заметного продвижения вэтомнаправлениине наблюдается.

Стандарт POSIX был создан как стандартный интерфейс сервисов операционных систем. Этот стандарт дает возможность создавать переносимые приложения. Впоследствии этот стандарт был расширенособенностями режимареального времени.

Спецификации POSIX задают стандартный механизм взаимодействия приложения и ОС.

Несмотря на то, что стандарт POSIX вырос из Unix, он затрагивает основополагающие абстракции операционных систем,

арасширения реального времени применимы ко всем ОСРВ.

Кнастоящему времени стандарт POSIX рассматривается как семейство родственных стандартов: IEEE Std 1003.n (где n — это номер).

Стандарт 1003.1a (OS Definition) содержит базовые интерфейсы ОС — поддержку единственного процесса, поддержку многих процессов, управление заданиями, сигналами, группами пользователей, файловой системой, файловыми атрибутами, управление файловыми устройствами, блокировками файлов, устройствами ввода/вывода, устройствами специального назначения, системными базами данных, каналами, очередями FIFO,

атакже поддержку языка C.

Стандарт 1003.1b (Realtime Extensions) содержит расши-

рения реального времени:

А. Диспетчеризация процессов реального времени

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