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

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

Поволжский государственный технологический университет

Реферат по дисциплине

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

Выполнил: студент ЭФ (группа ПИ-12)

Микушов Ю. В.

[email protected]

Преподаватель: Бородин А. В.

Йошкар-Ола

●Введение

●Определение

●Развитие современных операционных систем

●Современное состояние предметной области

●Отличия от операционных систем общего назначения

●Архитектура ОСРВ

●Типы задач ОС

●Пять важнейших невидимых задач ОС

●Особенности

●Применение

●Рынок операционных систем

●Будущее ОСРВ

●Заключение

●Список использованных источников

Введение

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

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

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

Принято различать системы мягкого (soft) и жесткого (hard) реального времени. В системах жесткого реального времени неспособность обеспечить реакцию на какие-либо события в заданное время ведет к отказам и невозможности выполнения поставленной задачи. В большинстве русскоязычной литературы такие системы называют системами с детерминированным временем. При практическом применении время реакции должно быть минимальным. Системами мягкого реального времени называются системы, не попадающие под определение "жесткие", т.к. в литературе четкого определения для них пока нет. Системы мягкого реального времени могут не успевать решать задачу, но это не приводит к отказу системы в целом. В системах реального времени необходимо введение некоторого директивного срока (в англоязычной литературе – deadline), до истечения которого задача должна обязательно (для систем мягкого реального времени – желательно) выполниться. Этот директивный срок используется планировщиком задач как для назначения приоритета задачи при ее запуске, так и при выборе задачи на выполнение.

Определения

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

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

Компоненты системы реального времени.

Прикладное программное обеспечение		Диспетчеризация
		Меж–потоковое взаимодействие
Операционная система реального времени		Обработка прерывания
	Защита от инверсии приоритетов	Управление потоками
		Управление памятью
Аппаратное обеспечение			Устройства

Расшифровка Mac OS X:

“Mac” означает название компании Macintosh.

“OS” – operating system, то есть операционная система.

“Х” – римское число десять, означает номер версии ОС.

Развитие современных операционных систем

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

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

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

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

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

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

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

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

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

Современное состояние предметной области

Ассоциации, компании и продукты

Компании Microsoft и Apple Inc. являются наиболее популярными производителями операционных систем и программного обеспечения к ним в современном мире.

Современные операционные системы от Microsoft:

Windows XP (Windows NT 5.1)

Windows Vista (Windows NT 6.0)

Windows 7 (Windows NT 6.1)

Windows 8 (Windows NT 6.2)

Windows 10 (Windows NT 10)

Современные операционные системы от Apple Inc:

Современные мобильные операционные системы:

Linux-системы (Android)

Отличия от операционных систем общего назначения

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

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

Архитектура ОСРВ

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

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

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

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

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

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

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

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

Типы задач

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

1. Циклические задачи. Характерны для процессов управления и интерактивных процессов.

2. Периодические задачи. Характерны для многих технологических процессов и задач синхронизации.

3. Импульсные задачи. Характерны для задач сигнализации и асинхронных технологических процессов.

Пять важнейших невидимых задач операционной системы

1. Обеспечивает аппаратно-программное «сцепление»

Операционная система служит своего рода «переводчиком» между аппаратной частью компьютера и его программным обеспечением. Если открыть корпус компьютера, то можно увидеть различные платы, чипы, кабели и другие компоненты. Это та физическая база, которая делает возможным выполнение программы. Но программа не может просто взять и использовать аппаратные ресурсы компьютера. Она делает это посредством операционной системы.

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

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

2. Заставляет одно и то же приложение работать на разном «железе»

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

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

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

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

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

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

3. Поиск необходимого приложению файла

Одних только физических ресурсов компьютера программам было бы недостаточно для того, чтобы корректно справляться со своими задачами. Вся информация хранится в файлах и этим файлам следует подчиняться определенным правилам. Эти правила касаются того, как именовать и хранить файлы. Мы называем этот общий набор правил «системой управления файлами» (file management system) или просто «файловым менеджером» («file manager»).

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

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

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

4. Эффективное распределение доступной оперативной памяти

Раз уж речь зашла о памяти, то имеет смысл вспомнить о памяти оперативной (ОЗУ, RAM). О том самом хранилище, которое всегда находится «под рукой» у процессора.

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

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

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

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

располагает определенным объемом оперативной памяти, который всегда ограничен. Этот объем зависит в том числе и от того, сколько программ вы одновременно запустили. Операционная система должна каждое мгновение «знать», сколько оперативной памяти у нее осталось в запасе, чтобы вовремя выделить ее процессу, который нуждается в этом важном ресурсе.

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

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

5. Акцентирует внимание процессора на той или иной задаче

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

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

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

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

Незаметная и незаменимая помощница

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

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

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

Особенности

Положительные особенности

Широкая распространенность продукта

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

Приятный интерфейс

У современных OC довольно приятный и понятный интерфейс. Это способствует быстрому восприятию информации, простоте использования компьютера, быстрому обучению работе с ОС.

Стабильность ОС

В общем и целом, стабильность работы современной OC можно назвать приемлемой. Однако слово "приемлемой" здесь должно сопровождаться массой оговорок:

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

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

3. Стабильность ОС также зависит и от самих приложений, установленных на ОС пользователем: чем они стабильнее в работе и чем более совместимы с самой программной оболочкой Windows, тем меньше сбоев мы сможем наблюдать в работе основной ОС.

4. На стабильность работы современной ОС большое влияние оказывает и само "железо", которое используется совместно с работающей ОС.

5. Также на стабильную работу современной OC далеко не последнее влияние оказывают драйверы устройств. Эти мини-программы, отвечающие за сопряжение определенного софта с определенным “железом”.

Хорошая совместимость с продуктами разных разработчиков (об OC Windows )

Современная OC способна корректно понимать любые типы файлов, появившиеся в ее ранних реинкарнациях. Если вспомнить те же расширения файлов, то станет ясно, что их родоначальником, по сути, является та самая примитивная и архаичная ОС, некогда перекупленная у стороннего разработчика и доведенная до ума Microsoft - MS-DOS. Эта преемственность файловых форматов тянется нитью через все версии Windows, что само по себе просто замечательно.

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Федеральное агентство по образованию

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

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

Введение

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

1.1 Типы ОСРВ

1.2 Структура ОСРВ

1.3 Процессы, потоки, задачи

1.4 Планирование, приоритеты

1.5 Память

1.6 Прерывания

1.7 Часы и таймеры

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

2.1 Стандарт POSIX

2.2 Стандарт DO-178B

2.3 Стандарт ARINC-653

2.4 Стандарт OSEK

2.5 Стандарты безопасности

3. Краткие характеристики распространённых операционных систем реального времени

3.2 QNX Neutrino RTOS

3.5 RTX (расширение реального времени для Windows NT)

3.6 INtime (расширение реального времени для Windows NT)

3.8 MicroWare OS-9

3.11 Nucleus RTOS

Заключение

Библиографический список

Введение

Концепции, лежащие в основе большинства существующих в наши дни операционных систем реального времени, уходят своими корнями в конец 70-х начало 80-х годов прошлого столетия.

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

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

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

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

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

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

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

Операционная система реального времени -- это тип операционной системы.

Есть много определений термина. Самые распространённые из них:

*Операционная система, в которой успешность работы любой программы зависит не только от её логической правильности, но и от времени, за которое она получила этот результат. Если система не может удовлетворить временным ограничениям, должен быть зафиксирован сбой в её работе;

*Стандарт POSIX 1003.1 даёт определение: «Реальное время в операционных системах -- это способность операционной системы обеспечить требуемый уровень сервиса в определённый промежуток времени»;

*Операционная система, реагирующая в предсказуемое время на непредсказуемое появление внешних событий;

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

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

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

Мартин Тиммерман (директор компании «Real-Time Consult и Real-Time User"s Support International (RTUSI)», обеспечивающей аппаратно-программную поддержку и занимающейся разработкой проектов систем реального времени) сформулировал следующие необходимые требования для ОСРВ:

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

*операционная система должна обладать понятием приоритета для потоков;

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

*операционная система должна обеспечивать механизм наследования приоритетов;

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

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

1.1 Типы ОСРВ

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

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

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

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

1.2 Структура ОСРВ

В течение последних 25-30 лет структура операционных систем (ОС) эволюционировала от монолитной к многослойной структуре ОС и далее к архитектуре клиент-сервер.

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

В многослойной структуре изменения одного слоя влияют на соседние слои, кроме того, обращение через слой невозможно.

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

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

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

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

1.3 Процессы, потоки, задачи

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

Концепция процесса, пришедшая из мира UNIX, плохо реализуется в многозадачной системе, поскольку процесс имеет тяжелый контекст. Возникает понятие потока (thread), который понимается как подпроцесс, или легковесный процесс (light-weight process). Потоки существуют в одном контексте процесса, поэтому переключение между потоками происходит очень быстро, а вопросы безопасности не принимаются во внимание. Потоки являются легковесными, потому что их регистровый контекст меньше, т.е. их управляющие блоки намного компактнее. Уменьшаются накладные расходы, вызванные сохранением и восстановлением управляющих блоков прерываемых потоков. Объем управляющих блоков зависит от конфигурации памяти. Если потоки выполняются в разных адресных пространствах, система должна поддерживать отображение памяти для каждого набора потоков.

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

1.4 Планирование, приоритеты

Главной проблемой в ОСРВ является планирование задач (scheduling), которое обеспечивало бы предсказуемое поведение системы при всех обстоятельствах. В связи с проблемами планирования в ОСРВ изучаются и развиваются два подхода - статические алгоритмы планирования (RMS - Rate Monotonic Scheduling) и динамические алгоритмы планирования (EDF - Earliest Deadline First).

RMS используется для формального доказательства условий предсказуемости системы. Для реализации этой теории необходимо планирование на основе приоритетов, прерывающих обслуживание (preemptive priority scheduling). В теории RMS приоритет заранее назначается каждому процессу. Процессы должны удовлетворять следующим условиям:

*процесс должен быть завершен за время его периода;

*процессы не зависят друг от друга;

*каждому процессу требуется одинаковое процессорное время на каждом интервале;

*у непериодических процессов нет жестких сроков;

*прерывание процесса происходит за ограниченное время.

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

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

Во всех системах реального времени требуется политика планирования, управляемая дедлайнами (deadline-driven scheduling). Однако этот подход находится в стадии разработки.

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

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

При планировании на основе приоритетов необходимо решить две обязательные проблемы:

*обеспечить выполнение процесса с наивысшим приоритетом,

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

Для борьбы с инверсией приоритетов в ОСРВ часто используется механизм наследования приоритетов, однако при этом приходится отказываться от планирования на основе RMS, поскольку приоритеты становятся динамическими.

1.5 Память

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

*Модель без защиты - системное и пользовательское адресные пространства не защищены друг от друга, используется два сегмента памяти: для кода и для данных, при этом от системы не требуется никакого управления памятью, не требуется MMU (memory management unit - специальное аппаратное устройство для поддержки управления виртуальной памятью);

*Модель защиты система/пользователь - системное адресное пространство защищено от адресного пространства пользователя, системные и пользовательские процессы выполняются в общем виртуальном адресном пространстве, при этом требуется MMU. Защита обеспечивается страничным механизмом защиты. Различаются системные и пользовательские страницы. Пользовательские приложения никак не защищены друг от друга. Процессор находится в режиме супервизора, если текущий сегмент имеет уровень 0, 1 или 2. Если уровень сегмента - 3, то процессор находится в пользовательском режиме. В этой модели необходимы четыре сегмента - два сегмента на уровне 0 (для кода и данных) и два сегмента на уровне 3. Механизм страничной защиты не добавляет накладных расходов, т.к. защита проверяется одновременно с преобразованием адреса, которое выполняет MMU; при этом ОС не нуждается в управлении памятью.

*Модель защиты пользователь/пользователь - к модели система/пользователь добавляется защита между пользовательскими процессами, требуется MMU. Как и в предыдущей модели, используется механизм страничной защиты. Все страницы помечаются как привилегированные, за исключением страниц текущего процесса, которые помечаются как пользовательские. Таким образом, выполняющийся поток не может обратиться за пределы своего адресного пространства. ОС отвечает за обновление флага привилегированности для конкретной страницы в таблице страниц при переключении процесса. Как и в предыдущей модели используются четыре сегмента.

*Модель защиты виртуальной памяти - каждый процесс выполняется в своей собственной виртуальной памяти, требуется MMU. У каждого процесса имеются свои собственные сегменты и, следовательно, своя таблица описателей. ОС несет ответственность за поддержку таблиц описателей. Адресуемое пространство может превышать размеры физической памяти, если используется страничная организация памяти совместно с подкачкой. Однако в системах реального времени подкачка обычно не применяется из-за ее непредсказуемости. Для решения этой проблемы доступная память разбивается на фиксированное число логических адресных пространств равного размера. Число одновременно выполняющихся процессов в системе становится ограниченным.

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

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

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

В обычных ОС при использовании механизма сегментации памяти для борьбы с фрагментацией применяется процедура уплотнения после сборки мусора. Однако такой подход неприменим в среде реального времени, т.к. во время уплотнения перемещаемые задачи не могут выполняться, что ведет к непредсказуемости системы. В этом состоит основная проблема применимости объектно-ориентированного подхода к системам реального времени. До тех пор, пока проблема уплотнения не будет решена, C++ и JAVA останутся не самым лучшим выбором для систем жесткого реального времени.

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

1.6 Прерывания

При описании управления прерываниями обычно различают две процедуры, а именно:

*программа обработки прерывания (ISR - interrupt servicing routine) - программа низкого уровня в ядре с ограниченными системными вызовами,

*поток обработки прерывания (IST - interrupt servicing thread) - поток уровня приложения, который управляет прерыванием, с доступом ко всем системным вызовам.

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

1.7 Часы и таймеры

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

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

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

Большинство ОСРВ оперируют относительным временем. Что-то происходит “до” и “после” некоторого другого события. В системе, полностью управляемой событиями, необходим часовой механизм (ticker), т.к. там нет квантования времени (time slicing). Однако, если нужны временные метки для некоторых событий или необходим системный вызов типа “ждать одну секунду”, то нужен тактовый генератор и/или таймер.

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

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

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

2.1 Стандарт POSIX

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

Наиболее ранним и распространенным стандартом ОСРВ является стандарт POSIX (IEEE Portable Operating System Interface for Computer Environments, IEEE 1003.1). Первоначальный вариант стандарта POSIX появился в 1990 г. и был предназначен для UNIX-систем, первые версии которых появились в 70-х годах прошлого века. Спецификации POSIX определяют стандартный механизм взаимодействия прикладной программы и операционной системы и в настоящее время включают набор более чем из 30 стандартов. Для ОСРВ наиболее важны семь из них (1003.1a, 1003.1b, 1003.1c, 1003.1d, 1003.1j, 1003.21, 1003.2h), но широкую поддержку в коммерческих ОС получили только три первых.

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

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

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

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

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

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

2.2 Стандарт DO-178B

Стандарт DO-178B, создан Радиотехнической комиссией по аэронавтике (RTCA, Radio Technical Commission for Aeronautics) для разработки программного обеспечения (ПО) бортовых авиационных систем.

Первая его версия была принята в 1982 г., вторая (DO-178A) - в 1985-м, текущая DO-178B - в 1992 г. Готовится принятие новой версии, DO-178C. Стандартом предусмотрено пять уровней серьезности отказа, и для каждого из них определен набор требований к программному обеспечению, которые должны гарантировать работоспособность всей системы в целом при возникновении отказов данного уровня серьезности

Данный стандарт определяет следующие уровни сертификации:

*А (катастрофический),

*В (опасный),

*С (существенный),

*D (несущественный)

*Е (не влияющий).

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

2.3 Стандарт ARINC-653

Стандарт ARINC-653 (Avionics Application Software Standard Interface) разработан компанией ARINC в 1997 г. Этот стандарт определяет универсальный программный интерфейс APEX (Application/Executive) между ОС авиационного компьютера и прикладным ПО.

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

2.4 Стандарт OSEK.

Стандарт OSEK/VDX является комбинацией стандартов, которые изначально разрабатывались в двух отдельных консорциумах, впоследствии слившихся. OSEK берет свое название от немецкого акронима консорциума, в состав которого входили ведущие немецкие производители автомобилей - BMW, Bosch, Daimler Benz (теперь Daimler Chrysler), Opel, Siemens и Volkswagen, а также университет в Карлсруэ (Германия). Проект VDX (Vehicle Distributed eXecutive) развивался совместными усилиями французских компаний PSA и Renault. Команды OSEK и VDX слились в 1994г.

Первоначально проект OSEK/VDX предназначался для разработки стандарта открытой архитектуры ОС и стандарта API для систем, применяющихся в автомобильной промышленности. Однако разработанный стандарт получился более абстрактным и не ограничивается использованием только в автомобильной индустрии.

Стандарт OSEK/VDX состоит из трех частей - стандарт для операционной системы (OS), коммуникационный стандарт (COM) и стандарт для сетевого менеджера (NM). В дополнение к этим стандартам определяется некий реализационный язык (OIL). Первым компонентом стандарта OSEK является стандарт для ОС, поэтому часто стандарт OSEK ошибочно воспринимается как стандарт ОСРВ. Хотя ОС и есть большая порция данного стандарта, мощность его состоит в интеграции всех его компонент.

2.5 Стандарты безопасности

В связи со стандартами для ОСРВ стоит отметить широко известный стандарт критериев оценки пригодности компьютерных систем (Trusted Computer System Evaluation Criteria - TCSEC). Этот стандарт разработан Министерством обороны США и известен также под названием "Оранжевая книга" (Orange Book - из-за цвета обложки).

В ряде других стран были разработаны аналогичные критерии, на основе которых был создан международный стандарт “Общие критерии оценки безопасности информационных технологий” (далее просто - Общие критерии) (Common Criteria for IT Security Evaluation, ISO/IEC 15408).

В "Оранжевой книге" перечислены семь уровней защиты:

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

*В3 - домены безопасности. Этот уровень предназначен для защиты систем от опытных программистов.

*В2 - структурированная защита. В систему с этим уровнем защиты нельзя допустить проникновение хакеров.

*В1 - мандатный контроль доступа. Защиту этого уровня, возможно, удастся преодолеть опытному хакеру, но никак не рядовым пользователям.

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

*С1 - избирательная защита. Этот уровень дает пользователям возможность защитить личные данные или информацию о проекте, установив средства управления доступом.

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

3. Краткие характеристики наиболее распространённых операционных систем реального времени

3.1 VxWorks

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

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

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

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

3.2 QNX Neutrino RTOS

Операционная система QNX Neutrino Real-time Operating System (RTOS) корпорации «QNX Software Systems» является микроядерной операционной системой, которая обеспечивает многозадачный режим с приоритетами.

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

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

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

3.3 RTEMS

RTEMS (Real-Time Executive for Multiprocessor Systems) - это некоммерческая операционная система реального времени для глубоко встраиваемых систем.

Разработчик системы компания «OAR» (On-Line Applications Research Corporation, США). Система была создана по заказу министерства обороны США для использования в системах управления ракетными комплексами. Система разрабатывается для многопроцессорных систем на основе открытого исходного кода в противовес аналогичным системам с закрытым кодом. Система рассчитана на платформы MS-Windows и Unix (GNU/Linux, FreeBSD, Solaris, MacOS X).

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

*мультизадачная обработка;

*работа в гомогенных и гетерогенных системах;

*планирование, управляемое событиями, на основе приоритетов;

*планирование с монотонной скоростью;

*взаимодействие задач и синхронизация;

*приоритетное наследование;

*управление ответным прерыванием;

*распределение динамической памяти;

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

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

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

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

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

3.4 ChorusOS

Операционная система ChorusOS - это масштабируемая встраиваемая ОС, широко применяемая в телекоммуникационной индустрии. В настоящее время этот бренд развивается и распространяется корпорацией «Sun Microsystems».

Для компоновки и развертывания ОС ChorusOS на конкретных телекоммуникационных платформах Sun Microsystems предлагает использовать среду разработки Sun Embedded Workshop. Корпорация Sun Microsystems представляет ОС ChorusOS как встраиваемую основу для Sun"овской сети, управляемой сервисами (Sun"s Service-Driven Network). В сочетании с широким набором сервисов, полной интеграцией ПО и аппаратуры, удобным администрированием и поддержкой Java-технологии, которая посвящена нуждам телекоммуникации, ОС ChorusOS дает возможность эффективно развертывать новые возможности и приложения, поддерживая надежность и функциональность современных сетей.

ОС ChorusOS поддерживает на одной аппаратной платформе широкий набор телекоммуникационных протоколов, унаследованных приложений, приложений режима реального времени и Java-технологии.

ОС ChorusOS моделирует три сорта приложений:

*POSIX-процессы составляют большинство приложений ChorusOS, эти приложения имеют доступ к POSIX API, нескольким POSIX-подобным расширенным API и небольшому числу ограниченных системных вызовов микроядра;

*Акторы ChorusOS - эти приложения выполняются над микроядром и ограничиваются API микроядра, акторы включают драйверы, события подсистем и протокольные стеки;

*Унаследованные приложения ChorusOS поддерживаются для совместимости с приложениями, разработанными для более ранних версий ChorusOS.

Архитектура ОС ChorusOS является многослойной, основанной на компонентах (component-based). Микроядро содержит минимальный набор компонентов, необходимых для функционирования ОС. Размер резидентной часть ядра составляет 10Kb.

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

ОС ChorusOS 5.0 лежит в основе операционной среды Solaris и поддерживает следующие целевые платформы:

*UltraSPARC II (CP1500 и CP20x0);

*Intel x86, Pentium;

*Motorola PowerPC 750 и семейство процессоров 74x0 (mpc7xx);

*Motorola PowerQUICC I (mpc8xx) и PowerQUICC II (mpc8260) (микроконтроллеры).

3.5 RTX (расширение реального времени для Windows NT)

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

*Windows NT проектировалась согласно современным технологиям построения ОС,

*программный интерфейс приложений (API) для Win32 стал де-факто стандартом для программистов,

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

*доступно большое количество драйверов устройств,

*доступны многие мощные интегрированные среды разработки.

Сама по себе Windows NT не подходит для применения в системах реального времени, поскольку в ней слишком мало приоритетных уровней, отсутствует механизм наследования приоритетов. Для минимизации времени обработки прерываний (ISR) в Windows NT введена концепция отложенного вызова процедуры (DPC - deferred procedure call), приоритет которой выше, чем приоритет пользовательских и системных потоков, в то время как все DPC имеют одинаковый приоритет. Это приводит к тому, что все DPC ставятся в очередь FIFO, и DPC с высокоуровневым прерыванием сможет выполниться только после того, как все другие DPC, стоящие в очереди перед ней, будут выполнены. Такие ситуации ведут к непредсказуемым временам отклика, что несовместимо с требованиями к ОСРВ. Управление памятью в Windows NT основано на механизме виртуальной памяти. Это тянет за собой защиту памяти, трансляцию адресов и подкачку, которая неприемлема в ОСРВ.

Расширение реального времени RTX (Real-Time Extension) для ОС Windows NT (разработано корпорацией «VenturСom») позволяет создавать приложения для высокоскоростного управления с детерминированным временем реакции на внешние события.

RTX глубоко интегрировано в ядро Windows NT и для обеспечения необходимых функций использует сервис Windows NT и API WIN32. Ядро реального времени (nucleus) интегрировано в ядро NT (kernel). Каждый процесс RTX выполняется как драйвер устройства ядра NT, при этом процессы не защищены друг от друга. Такая реализация приводит к быстрому переключению контекста, но небезопасна с точки зрения конфиденциальности.

3.6 INtime (расширение реального времени для Windows NT)

Система INtime является расширением реального времени Windows, которое было разработано корпорацией «Radisys Corporation», а в настоящее время поддерживается корпорацией TenAsys.

INtime комбинирует возможности ОСРВ жесткого реального времени со стандартными ОС Windows, включая Windows XP, Windows XP Embedded, Windows 2000, Windows NT и Windows NT Embedded, не требуя дополнительной аппаратуры. INtime специально разработана под архитектуру процессора x86.

INtime, в отличие от RTX, слабо связана с NT. Архитектура INtime основана на механизме аппаратного обслуживания задач (hardware tasking), которое обеспечивается процессором Intel. Получается, что два ядра выполняются на одной аппаратуре. Поскольку они разделяют одну аппаратуру, потребовались некоторые модификации NT HAL. Такой подход позволяет защитить и отделить среду выполнения и область памяти от Windows. Внутри INtime каждый процесс приложения имеет свое собственное адресное пространство. Кроме того, ядро и приложения выполняются на разных приоритетных уровнях, что позволяет защитить их друг от друга.

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

3.7 LynxOS

Операционная система LynxOS RTOS (LynuxWorks, Inc.) является операционной системой жесткого реального времени, которая предназначена для специализированной и телекоммуникационной аппаратуры. Эта ОС является полностью детерминированной и обладает POSIX-, UNIX- и Linux-совместимостью. Областями применения ОС LynxOS являются также сложные системы безопасности.

Последняя выпущенная версия этого бренда ОС LynxOS-178 2.0 характеризуется производителем как коммерческая операционная система, обеспечивающая высокий уровень надежности и оперативности, необходимый для встраиваемых приложений с особыми требованиями к безопасности. В LynxOS-178 2.0 реализована поддержка интерфейса APEX (Application/EXecutive - интерфейс приложения/управляющей программы) спецификации ARINC-653. Это означает, что данная операционная система отвечает самым строгим требованиям к безопасности и надежности электронных систем для военной и гражданской авиации. Система LynxOS-178 2.0 полностью соответствует положениям уровня А спецификации DO-178B.

ОСРВ LynxOS-178 2.0 соответствует требованиям стандартов POSIX и ARINC-653, а также DO-178B, что означает гарантию переносимости прикладного кода встраиваемых систем, многократного использования созданных программ, а также соответствие самым строгим нормативам операционных систем с повышенными требованиями к безопасности. Использование LynxOS-178 2.0 позволяет применять любые ранее сертифицированные программы и разработки.

3.8 MicroWare OS-9

Операционная система реального времени OS-9 корпорации «Microware System» является многозадачной, многопользовательской операционной системой для встраиваемых приложений, работающих в режиме реального времени. Эта система предназначена для работы в таких системах, как мобильные телекоммуникационные устройства, встраиваемые терминалы доступа в Интернет, интерактивные цифровые телевизионные приставки.

OS-9 работает на таких процессорах, как Motorola 68K, ARM/StrongARM, Intel IXP1200 Network Processor, MIPS, PowerPC, Hitachi SuperH, x86 or Intel Pentium, Intel IXC1100 XScale.

Ядро OS-9 является масштабируемым, полностью вытесняемым, поддерживает функционирование до 65535 процессов, предоставляет 65535 уровней приоритета и обеспечивает работу до 255 пользователей. Ядро OS-9 содержит более 90 системных вызовов, которые дают возможность управлять динамическим режимом диспетчеризации, распределением памяти, межпроцессорной коммуникацией и т.д. - вплоть до управления встраиваемым в ядро ОС режимом экономичного потребления питания.

Корпорация Microware одной из первых лицензировала Java для встраиваемых приложений и является лидером по предложению разнообразных средств и приложений в рамках OS-9 для различных классов устройств.

В качестве интегрированной кросс-среды разработки приложений для OS-9 корпорация Microware разработала среду Hawk, которая функционирует на платформе MS Windows NT.

3.9 OSE RTOS

Операционная система реального времени OSE RTOS, разработанная в корпорации «ENEA», имеет ядро с приоритетным планированием. Это ядро сильно оптимизировано для обеспечения высокой производительности и достаточно компактно для использования во встраиваемых системах. OSE имеет архитектуру, управляемую сообщениями, с простыми системными вызовами. Передача сообщений в OSE служит концептуальным шлюзом в распределенных многопроцессорных встраиваемых системах. Задачи посылают сообщения друг другу напрямую через ОС без поддержки очередей, почтовых ящиков или других промежуточных механизмов. OSE RTOS поддерживает подкачку, дублирование, динамическое обновление кода и многие коммуникационные протоколы.

Архитектура OSE RTOS основана на многослойной модели.

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

В OSE RTOS разделение процессов понимаются как динамические и статические: статические процессы создаются ядром, когда система стартует, и существуют на всем протяжении существования системы, динамические процессы создаются и уничтожаются во время выполнения.

3.10 Windows CE

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

Windows CE имеет ограничение на физическую память - 512MB. Microsoft ввел это ограничение для того, чтобы Windows CE могла выполняться на большом диапазоне встраиваемых процессоров без проблем совместимости, поскольку некоторые из этих процессоров способны управлять физической памятью в 512MB. Windows CE реализует страничное управление виртуальной памятью. Размер страницы зависит от платформы, но, по возможности, используется размер в 4KB. Есть возможность запретить страничную организацию, что важно для систем реального времени. В этом режиме модуль перед выполнением целиком загружается в память. Тогда страничная подкачка (paging) не повлияет на выполнение приложения.

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

3.11 Nucleus RTOS

Операционная система Nucleus, разработанная корпорацией «Accelerated Technology», предназначена для встраиваемых приложений.

Nucleus является кросс-системой, т.е. программный продукт создается на одной программно-аппаратной платформе, а выполняется на другой.

ОСРВ Nucleus поставляется вместе с открытым кодом.

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

Nucleus PLUS предоставляет такие возможности, как управление взаимодействием задач (почтовые ящики, очереди, конвейеры, семафоры, события, сигналы), а также управление памятью, таймерами, прерываниями. Планирование задач осуществляется на основе приоритетов, а также по алгоритму FIFO.

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

Заключение

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

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

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

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

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

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

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

Библиографический список

1. Бурдонов И.Б., Косачёв А.С., Пономаренко В.Н. Операционные системы реального времени. Препринт: Института системного программирования РАН. Иркутск, 2006.

2. Олифер В.Г., Олифер Н.А. Сетевые операционные системы: Учебник для вузов. 2-е изд.- СПБ.: Питер, 2008. - 669 с.: ил.

3. www.ru.wikipedia.org

4. www.intuit.ru

Подобные документы

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

контрольная работа , добавлен 09.03.2013

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

реферат , добавлен 28.12.2007

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

курсовая работа , добавлен 17.12.2015

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

реферат , добавлен 11.12.2011

Обзор требований проблемной области. Особенности управления задачами. Исполнительные системы реального времени. Программирование на уровне микропроцессоров. Модели и методы предметной области. Реализация прототипа системы реального времени.

курсовая работа , добавлен 15.02.2005

Планирование задач в операционной системе реального времени. Основные виды планирования применительно к задачам реального времени. Выбор приемлемого алгоритма планирования при проектировании RTS. Статическое прогнозирование с использованием таблиц.

контрольная работа , добавлен 28.05.2014

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

курсовая работа , добавлен 19.01.2015

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

курсовая работа , добавлен 18.05.2014

Понятие и функции операционной системы. Основная особенность операционных систем реального времени. Работа с электронными таблицами. Фильтрация записей в таблице MS Excel. Установка пользовательского автофильтра в оборотную ведомость движения товаров.

контрольная работа , добавлен 21.11.2013

Сущность и принцип работы операционной системы, правила и преимущества ее использования. Возможности различных операционных систем, их сильные и слабые стороны. Сравнительная характеристика систем Unix и Windows NT, их потенциал и выполняемые задачи.

(Real Time Operating Systems - RTOS) относятся к программным средствам и предназначены для обслуживания цифровых систем в тех случаях, когда:

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

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

Принцип работы ОСРВ

При поступлении запроса производится проверка на входные данные для решения задачи. При их наличии задача начинает выполняться. ЕСЛИ необходимые входные данные отсутствуют, то ОСРВ переходит к следующей задаче (при наличии запроса на ее выполнение). Для получения входных данных и запуска соответствующей задачи используются прерывания. Запуск задачи обычно производится путем ее пересылки из очереди ожидающих задач в очередь задач, предназначенных для выполнения.

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

Системные ресурсы (дисковые накопители, таймеры, устройства ввода–вывода и др.) обычно доступны только для определенных задач. Это позволяет организовать очередь запросов к ресурсам таким образом, чтобы предотвратить одновременный доступ к одному ресурсу нескольким задачам.

Требования к ОСРВ.

Современные ОС PB должны удовлетворять следующим требованиям:

● малое время отклика (получение результата);

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

● малый объем памяти (достаточный для размещения в резидентной памяти прикладной системы);

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

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

Типы ОСРВ

Можно выделить два типа ОСРВ:

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

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

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

Этот вид систем рассмотрим на примере системы OS–9 фирмы Microwave Systems . В качестве инструментального компьютера OS –9 использует IBM – PC , работающие в среде Windows , или рабочие станции Sun, HP, IBM RS /6000 с операционными системами типа UNIX . Характерные особенности OS –9:

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

● гибкость структуры, обеспечивающая реконфигурацию системы и расширение ее функциональных возможностей. Функциональные компоненты OS–9:

● ядро реального времени (OS –9 kernel);

● общие средства ввода/вывода (I / O man);

● файловые менеджеры;

● средства разработки программ.

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

Рассмотрим Перечисленные выше функциональные компоненты.

Ядро реального времени

Система содержит два вида ядер:

● ядро Atomic , реализующее минимальное количество сервисных функций (дистанционную загрузку, связь с локальной сетью, управление ведомыми микроконтроллерами). Ядро применяется в системах, встраиваемых в различную аппаратуру, имеет малый объем (24 Кбайт) и обеспечивает минимальное время отклика (3 мкс при тактовой частоте 25 МГц);

● ядро Standard , обеспечивающее выполнение широкого набора функций сервиса и разработки прикладных программ, для реализации которых требуется больший объем памяти (до 512К байт ПЗУ и 38К байт ОЗУ). Путем изменения функциональных модулей ядра можно реализовать системы различной сложности и назначения: от встраиваемых в аппаратуру контроллеров с резидентным программным обеспечением и простейшими средствами ввода/вывода до сложно функциональных систем класса рабочих станций с развитой сетевой поддержкой и обеспечением разнообразных функций сервиса, включая мультимедиа.

Система OS –9 предоставляет пользователю возможность выбора ядра в зависимости от функционального назначения системы. Общие средства ввода/вывода. Физический интерфейс OS –9 с разнообразными внешними устройствами обеспечивается большим набором драйверов, созданных как фирмой Microwave Systems , так и многочисленными разработчиками аппаратуры, использующей эту операционную систему для конкретных приложений. Файловые менеджеры. К ним относятся модули, управляющие логическими потоками данных. Каждый из модулей имеет определенное функциональное назначение и спецификацию. Файловые менеджеры можно разделить на три группы:

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

● сетевые и коммуникационные менеджеры, обеспечивающие работу OS –9 с различными сетями и обмен данными по каналам связи с наиболее распространенными стандартами протоколов обмена;

● менеджеры графического интерфейса и работы с мультимедиа–приложениями. Средства разработки программ. В составе OS –9 имеется пакет программ (BSP) для поддержки плат развития, который обеспечивает совместную работу OS–9 с целым рядом SBC (Single Board Computer - одноплатный компьютер). Совместное использование BSP и OS–9 позволяет сконфигурировать целевую систему для конкретного приложения.

Система OS–9 содержит средства поддержки программирования: компиляторы Ultra C/C++, текстовый редактор ЕМ ACS , три вида (в том числе символьных) отладчиков, набор утилит для организации контроля и сборки программных продуктов. Помимо этого имеется большой набор (совместимых с OS –9) средств поддержки программирования, которые разработаны другими фирмами. FasTra к. Среда FasTrak поставляется совместно с OS–9 и предоставляет пользователю наиболее полный комплект средств программирования и отладки. Часть программных средств FasTrak инсталлируется на инструментальном компьютере, а часть - на целевой системе пользователя. Среда FasTrak интегрирует все средства, необходимые для поддержки проектирования/отладки целевых систем. Версия среды FasTrak для работы на инструментальном компьютере IBM – PC содержит:

● текстовый редактор, располагающий средствами перекодировки клавиатуры, что позволяет вести редактирование в удобном для пользователя формате;

● компиляторы Ultra C/C++;

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

● средства интерфейса с логическими анализаторами фирмы.

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

Фирма Microware Systems поставляет ряд системных пакетов, ориентированных на различные сферы приложения:

● Wireless OS –9 - для разработки устройств беспроводной связи: сотовых телефонов, пейджеров, портативных цифровых ассистентов (PDA);

● Internet OS –9 - для разработки устройств с доступом к сети Internet ;

● Digital Audio / Video Interactive Decoder (DAVID) OS –9 - для разработки распределенных систем цифрового интерактивного телевидения.

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

Особенности этого вида систем рассмотрим на примере системы VxWorks фирмы WindRiver Systems , предназначенной для работы с семействами микропроцессоров многих производителей. Система VxWorks инсталлируется на отлаживаемой целевой системе и работает совместно с интегрированной средой разработки Tornado , функционирующей на инструментальном компьютере. В качестве инструментального компьютера используются IBM – PC , работающие в среде Windows , или рабочие станции SUN, HP и др. Краткое описание системы VxWorks. Нижним уровнем иерархической организации системы служит микроядро реального времени, выполняющее базовые функции планирования задач и управления их связью и синхронизацией. Минимальный набор модулей ядра занимает 20–40К байт памяти. Все остальные функции - управление памятью, вводом/выводом, сетевым обменом и другие, реализуются дополнительными модулями. Для поддержки графических приложений VxWorks располагает графическим интерфейсом VX–Windows.

При ограниченном объеме памяти целевой системы можно воспользоваться графической библиотекой RTGL, которая содержит базовые графические примитивы, наборы шрифтов и цветов, драйверы типовых устройств ввода и графических контроллеров. В состав VxWorks входят также различные средства поддержки разнообразных сетевых протоколов. Трассировку заданных событий и их накопление в буферной памяти для последующего анализа выполняют в реальном времени специальные средства отладки, а трассировку системных событий - динамический анализатор WindView . Анализатор WindView работает аналогично логическому анализатору, отображая на экране временные диаграммы переключения задач, записи в очередь сообщений и другие процессы. Монитор данных Stethoscope позволяет анализировать динамическое изменение пользовательских и системных переменных, включая в себя также профилировщик процедур. В составе VxWorks имеется:

● пакет программ для поддержки плат развития;

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

Для комплексной отладки целевых систем VxWorks обеспечивает интерфейс со схемными эмуляторами и эмуляторами ПЗУ. Интегрированная среда разработки Tornado . В состав Tornado входит система VxWorks 5.3, включающая ядро реального времени и системные библиотеки, средства программирования, высокоуровневый отладчик и ряд других средств системы. Дополнительные средства среды Tornado обеспечивают управление процессом отладки, визуализацию состояния целевой системы, другие сервисные функции. Открытая архитектура среды Tomado позволяет пользователю подключать собственные специализированные инструментальные средства и расширять возможности стандартных средств.

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

Программные продукты и системы № 4, 2001 г. garbage collection. Technical report, University of Texas at Austin, 1993. 3. Kim T., Chang N., Kim N., Shin H. Scheduling Garbage Collector for Embedded Real-Time Systems. Technical report, Seoul National University. 4. The real-time specification for Java. http://www.rtj.org. 5. International J consortium specification. Real-time Core extensions. www.j-consortium.org. 6. Никифоров В.В., Данилов М.В. Статическая обработка спецификаций программных систем реального времени. //Программные продукты и системы.- 2000.- №4.- С.13-18. 7. Henriksson R. Scheduling garbage collection in embedded systems. Lund, 1998. 8. Nilsen K., Lee S. PERC real-time API. NewMonics Inc., 1997. 9. Wilson P.R., Johnstone M.S., Neely N., Boles D. Dynamic storage allocation: a survey and critical review. Technical report, University of Texas at Austin, 1995. МЕЖДУНАРОДНЫЙ СТАНДАРТ OSEK/VDX ДЛЯ ОПЕРАЦИОННОЙ СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ М.П. Червинский Одной из тенденций совершенствования конструкций современных автомобилей является расширяющееся внедрение встроенных компьютерных систем. Соответственно растет объем производства автомобильных приложений реального времени – программных продуктов, обеспечивающих функционирование этих систем. Рост объема производства сопровождается ужесточением сроков разработки программных приложений, требований снижения их стоимости с одновременным улучшением надежности, мобильности, пригодности к повторному использованию при разработке новых продуктов. Перечисленные факторы стимулируют разработку стандартов, регламентирующих архитектурные и технологические решения, специфицирующие программные и сетевые интерфейсы для автомобильных приложений реального времени. Подобные стандарты должны способствовать расширению возможностей интеграции программных продуктов, производимых различными поставщиками программных средств. Во внедрении таких стандартов заинтересованы и крупные автомобилестроительные концерны, ("Крайслер", БМВ, "Фольксваген" и другие), стремящиеся к созданию конкуренции на рынке программных продуктов, которые они используют, потому что конкуренция позволяет приобретать программные продукты поставщиков, предлагающих наилучшее соотношение цена/качество. Для того чтобы смена поставщика не приводила бы к необходимости переработки значительной части приложений, производители требуют использования стандартов всеми поставщиками программных продуктов. Большинство встроенных систем, применяемых в транспортных средствах, являются приложениями жесткого реального времени. Обработка событий, возникающих в них, ограничивается жесткими сроками, нарушение которых могло бы привести к катастрофическим последствиям . В настоящее время основной технологией, применяемой для создания автомобильных приложений реального времени и, в частности, приложений жесткого реального времени, становится использование ядра, или операционной системы реального времени (ОСРВ). ОСРВ позволя- 40 ет разработчикам приложений гарантировать работоспособность приложения на протяжении всего цикла работы системы при условии правильного выбора приоритетов задач и правильного проектирования приложения. Необходимость стандартизации автомобильных приложений, строящихся на базе ОСРВ, привела к созданию в 1995 году международного комитета, осуществляющего проект OSEK/VDX создания международных стандартов, регламентирующих разработку программных средств для компьютерных систем, встраиваемых в автомобили. Проект OSEK/VDX был инициирован группой ведущих европейских производителей транспортных средств (автомобилей), большинство из которых находятся в Германии. Именно поэтому выбранная аббревиатура OSEK является сокращением немецкого названия «Offene Systeme und deren Schnittstellen für die Elektronik im Kraftfahrzeug» – «Открытые системы и интерфейсы для автомобильной электроники». Сокращение же VDX означает «Vehicle Distributed eXecutive» – название другого проекта, интеграция с которым произошла практически одновременно с началом проекта OSEK. Таким образом, даже название проекта и серии стандартов отражает интернациональный характер разработки с некоторым доминированием немецких производителей. В рамках проекта OSEK/VDX разрабатываются несколько стандартов. 1. OSEK/VDX OS (Operating System) – спецификация ОСРВ . Спецификация содержит описание архитектуры ОС, определение программного интерфейса ОС, которое следует использовать приложению, а также детальное описание поведения ОС и ее компонент. Следует отметить, что стандарт специфицирует по сути архитектуру и функции ядра реального времени, а не полноценную ОС, так как не содержит таких существенных компонент ОС, как, например, подсистема управления вводом-выводом, или подсистема распределения памяти. 2. OSEK/VDX COM (Communication) – спецификация сетевой подсистемы . Спецификация определяет программные интерфейсы и протоколы, предназначенные для передачи данных между узла- Программные продукты и системы ми транспортного средства. Современный автомобиль содержит до нескольких десятков микроконтроллеров, обменивающихся информацией. Как правило, используются как минимум две подсети: высокоскоростная – для системы управления двигателем, трансмиссией и подвеской, и низкоскоростная – для кузовной электроники. Программный интерфейс обеспечивает прозрачную передачу данных, то есть единый набор функций используется для обмена сообщениями как внутри узла, так и между узлами сети. Несмотря на то что спецификация в целом обеспечивает пользователей всеми необходимыми средствами для создания локальной сети автомобиля и поддерживает другие стандарты, применяемые в автомобильной индустрии, внедрение продуктов, реализующих OSEK/VDX COM, в реальные проекты сопряжено с некоторыми проблемами. Главной является использование крупными производителями автомобилей других (нестандартных) протоколов, что затрудняет переход на OSEK/VDX COM, так как требуется либо менять сетевое обеспечение во всех узлах автомобиля, либо поддерживать одновременно как стандартный, так и нестандартный протокол, по крайней мере в некоторых узлах сети. Кроме того, в настоящей версии спецификаций отсутствует механизм передачи данных длиной в несколько бит, а именно данные такой длины составляют существенную долю сетевого трафика автомобиля. Поэтому разработка спецификаций OSEK/VDX COM продолжается. 3. OSEK/VDX NM (Network Management) – спецификация управления сетью. Спецификация определяет, каким образом информация о текущем состоянии каждого из узлов сети передается другим узлам. Для этого используется метод мониторинга, в частности, две его разновидности – прямой и косвенный. Прямой мониторинг основан на передаче специальных сообщений по логическому кольцу или логической звезде. Косвенный мониторинг основан на отслеживании обычных сообщений, передаваемых узлами. OSEK/VDX NM может быть интегрирован с другими сетевыми системами (а не только с OSEK/VDX COM), и поэтому используется в настоящее время вместе с нестандартными сетевыми системами. 4. OSEK/VDX OIL (OSEK Implementation Language) – спецификация языка конфигурации системы. Спецификация описывает язык, использующийся для конфигурации приложений, построенных на реализации OSEK/VDX. Во встроенных системах, применяемых в автомобилях, все объекты приложения конфигурируются статически на стадии компиляции. Язык OIL содержит конструкции, позволяющие описать свойства системных объектов, например, названия и приоритеты задач, параметры таймеров и сообщений и т.п. Описание конфигурации обрабатывается специальной утилитой (системным генератором), которая формирует заголовочные файлы и исходный код, описывающие системные таблицы. В настоящее время не все спецификации полностью покрываются OSEK/VDX OIL (в частности, отсутст- № 4, 2001 г. вуют описания для объектов OSEK/VDX COM), поэтому работа над этим стандартом продолжается. Перечисленные спецификации разрабатываются разными рабочими группами во многом независимо друг от друга, но на определенных этапах производится коррекция и синхронизация спецификаций. Синхронизированные версии заносятся в спецификацию связей – специальный документ, содержащий описание всего проекта и аннотации составляющих его частей. Помимо перечисленных спецификаций, в рамках проекта OSEK/VDX разрабатываются спецификации систем, управляемых временем (timetriggered) . В настоящее время, однако, разработка еще не доведена до стадии издания официальных документов. Спецификация OSEK/VDX OS. Последним официально выпущенным документом является редакция 1 версии 2.1 от 13 ноября 2000 года. Эта редакция является результатом тщательной переработки предыдущей редакции 1 версии 2.0, в которой было обнаружено несколько серьезных дефектов и сотни мелких замечаний. Дефекты были обнаружены как разработчиками собственно ОСРВ, так и создателями приложений. Несколько дефектов были настолько серьезны, что делали невозможным создание корректно работающей ОСРВ на некоторых аппаратных платформах. Рабочая группа крайне ответственно подошла к исправлению дефектов и замечаний. Достаточно сказать, что полный список проблем и предлагаемых решений содержал больше страниц, чем собственно спецификация. Спецификация OSEK/VDX OS определяет программный интерфейс для выполнения функций ОСРВ. Программный интерфейс специфицирован на языке программирования С (используется стандарт ANSI-C), хотя реализация ОСРВ возможна и на других языках программирования. Мобильность приложений поддерживается на уровне исходного кода. Предполагается, что приложение может быть просто перекомпилировано при замене реализации ОСРВ. Однако стопроцентная мобильность все же не гарантируется, и при переносе приложения с одной платформы на другую могут потребоваться некоторые изменения как исходного кода, так и описания конфигурации. Связано это с тем, что в спецификации определены функции, зависящие от реализации, а конфигурация может включать атрибуты, предназначенные для оптимизации ОСРВ и приложения для конкретной реализации. Однако усилия по переносу приложения все же существенно ниже, чем при использовании нестандартных ОСРВ, и перенос может быть выполнен на этапе интеграции, а не собственно разработки программного обеспечения. Содержание спецификации OSEK/VDX OS. Спецификация содержит разделы, регламентирующие: архитектуру ОС, управление задачами, обработку прерываний, обработку событий, синхронизацию с помощью разделяемых ресурсов, алармы (управление по таймерам и счетчикам), передачу сообщений, обработку ошибочных ситуаций и отладку, описание системных вызовов. 41 Программные продукты и системы Имеется также раздел, определяющий особенности реализации ОСРВ и список изменений (контроль версий). Следует отметить, что спецификация разделяет нормативные требования (обязательные) и просто описательные части, поясняющие особенности спецификации. Ниже рассматриваются основные особенности ОС, отвечающих спецификациям OSEK/VDX OS. Архитектура ОС. Строго говоря, архитектура ОСРВ не описана в спецификации, поскольку не отличается от традиционно используемой в ядрах реального времени, и раздел содержит скорее общее описание принципов работы ОСРВ. ОСРВ управляет двумя типами объектов, конкурирующих за право использования процессора, – задачами и обработчиками прерывания. Задачи конкурируют на основе программно задаваемых статических приоритетов, то есть ОСРВ поддерживает планирование с фиксированными приоритетами. Обработчики прерывания имеют более высокий приоритет, чем задачи и планируются с помощью аппаратного обеспечения. Вследствие такого распределения приоритетов любое переключение контекста задач, вызванное выполнением системных вызовов в обработчиках прерываний, задерживается до завершения обработчика прерывания или завершения самого внешнего обработчика при обработке вложенных прерываний. Соответственно двум типам конкурирующих объектов спецификация определяет два уровня работы – уровень задач и уровень прерываний. Определен также логический уровень планировщика, хотя этот уровень не используется в спецификации и не виден пользователю ОСРВ. Следует отметить, что, несмотря на полностью статическое распределение приоритетов задач и обработчиков прерываний, во время выполнения приложения могут возникнуть ситуации ограниченной по времени инверсии приоритетов. Это происходит, когда низкоприоритетная задача вытесняет более приоритетные задачи или задача запрещает выполнение обработчиков прерываний вплоть до некоторого порогового уровня аппаратного прерывания. Возникновение таких ситуаций объясняется использованием протокола синхронизации при доступе к критическим секциям и полностью контролируется приложением. Однако ни при каких обстоятельствах не возникает неограниченной по времени инверсии приоритетов, что позволяет гарантировать своевременность исполнения задач при правильном статическом назначении приоритетов. Классы соответствия. Одним из основных требований к OSEK/VDX OS является возможность применения ОСРВ на процессорах различной мощности, начиная с 8-битных микроконтроллеров, имеющих несколько десятков килобайт ПЗУ и несколько килобайт ОЗУ, и заканчивая 32-битными процессорами, имеющими сотни килобайт ПЗУ и ОЗУ. Для выполнения этого требования спецификация, в частности, описывает четыре класса соответствия. Классы соответствия определяются следующими характеристиками: а) множественный запрос 42 № 4, 2001 г. активизации (разрешен или нет в данном классе); б) поддержка задач с состоянием ожидания, то есть так называемых расширенных задач; в) количество задач на один уровень приоритета; г) обязательные (минимальные) количественные параметры ОСРВ (например, количество исполняемых задач, число поддерживаемых ресурсов для доступа к критическим секциям и т.п.). Спецификация определяет следующие классы соответствия. Базовый класс 1 (BCC1 – Basic Conformance Class 1). Задачи с состоянием ожидания и множественный запрос активизации не поддерживаются, только одна задача на уровень приоритета, то есть все задачи имеют разный приоритет. Базовый класс 2 (BCC2). То же, что базовый класс 1, но поддерживаются множественный запрос на активизацию и несколько задач на один уровень приоритета. Расширенный класс 1 (ECC1 – Extended Conformance Class 1). То же, что базовый класс 1, но поддерживаются задачи с состоянием ожидания. Расширенный класс 2 (ECC2). То же, что ECC1, но поддерживаются множественный запрос на активизацию для задач без состояния ожидания и несколько задач на один уровень приоритета. Классы соответствия помогают как разработчикам ОСРВ, так и пользователям корректно характеризовать и использовать реализации системы. Следует отметить, что поставщики OSEK/VDX OS могут реализовать только несколько классов соответствия, для того чтобы получить сертификат соответствия стандарту. Пользователи, особенно крупные корпорации, обычно требуют от разработчиков приложений использовать только определенные классы соответствия или даже только один класс, для того чтобы облегчить интеграцию, уменьшить требования к расходуемым ресурсам (например к памяти), и иметь гибкость при смене поставщика ОСРВ. Дело в том, что каждый следующий класс, хотя это и не описано явно, требует более громоздкой реализации, поэтому есть смысл ограничить требования приложений минимально необходимым классом. Например, множественный запрос активизации требует ощутимых дополнительных расходов как памяти, так и циклов процессора, поэтому нет смысла использовать классы, поддерживающие множественный запрос, если такая возможность не используется в приложении. Классы соответствия обеспечивают грубую классификацию ОСРВ, которой полезно придерживаться. В то же время поставщики ОСРВ вправе добавить улучшения в реализацию класса соответствия. Например, во многих реализациях поддерживается схема несколько задач на один уровень приоритета даже для базового класса соответствия 1. В целом приложения, требующие высокой производительности, например системы управления впрыском топлива в двигатель, могут использовать базовый класс 1, потому что он обеспечивает самое быстрое переключение задач, синхронизированное с углами поворота распредвала, и повторная активизация задачи (то есть множественный запрос активиза- Программные продукты и системы ции) рассматривается как перезагрузка. Для кузовной электроники зачастую используется расширенный класс 1, так как с помощью задач с состоянием ожидания удобно реализовывать конечные автоматы. Управление задачами. ОСРВ поддерживает планирование задач с фиксированными приоритетами и три различных способа диспетчеризации – вытесняющую, невытесняющую и смешанную (в спецификации диспетчеризация объединена с планированием, и отдельно этот термин не используется). При вытесняющей диспетчеризации задача с более высоким приоритетом всегда вытесняет из обработки задачу с более низким приоритетом. При невытесняющей диспетчеризации такое вытеснение происходит, только если низкоприоритетная задача сама освободит процессор. При смешанной диспетчеризации некоторые задачи являются вытесняемыми, а некоторые – невытесняемыми. Следует отметить, что обработка прерываний выполняется одинаково при любом способе диспетчеризации. При планировании равноприоритетных задач соблюдается принцип первой запланирована – первой выполняется. Как правило, приложения используют вытесняющую диспетчеризацию, позволяющую добиться соблюдения сроков исполнения с помощью относительно простых правил назначения приоритетов. Повидимому, невытесняющая диспетчеризация может использоваться в приложениях с существенно ограниченным числом задач и совместно используемых ресурсов. В связи с тем, что контекст невытесняемых задач содержит меньше регистров процессора, переключение контекста выполняется быстрее, и, следовательно, можно добиться более высокой производительности при более низких расходах памяти. Совмещенная диспетчеризация полезна в тех случаях, когда существует несколько задач не очень высокого приоритета, которые выполняются настолько быстро, что не имеет смысла расходовать время процессора на их вытеснение. OSEK/VDX OS специфицирует два типа задач – базовые и расширенные. Базовые задачи могут быть только в одном из трех состояний – неактивном, готовом и выполняющемся. Расширенные задачи могут дополнительно находиться в ждущем состоянии. Неактивное состояние задачи похоже на программу ОС общего назначения, находящуюся на жестком диске. Предполагается, хотя и не описано явно, что неактивная задача не использует ОЗУ. Спецификация также не накладывает ограничений на количество неактивных задач в приложении, что позволяет предположить, что таких задач может быть много больше, чем активизированных. Базовые задачи поддерживают принцип однократного выполнения, то есть при активизации задача переходит из неактивного состояния в готовое, затем, в зависимости от приоритета и способа диспетчеризации, занимает процессор, переходя в состояние выполнения. После окончания работы эта задача завершается и возвращается в неактивное состояние. Задачи такого рода никогда не используются в ОС общего назначения, но они эффективны во встроенных приложениях реального времени. № 4, 2001 г. Расширенные задачи могут переходить в состояние ожидания посредством механизма событий. Если все события, которые ожидает задача, не установлены, то задача переходит в состояние ожидания до тех пор, пока хотя бы одно из ожидаемых событий не будет установлено. Спецификация не определяет способа завершения одной задачи из другой или обработчика прерывания. Поэтому переход в неактивное состояние возможен только из состояния выполнения. Иными словами, задача может завершиться только по собственной инициативе. Разновидностью завершения задачи является завершение с одновременной активизацией другой задачи или нового экземпляра той же самой задачи, что позволяет создавать цепочки задач. Повторная активизация уже активной задачи приводит к ошибке в классах соответствия BCC1 и ECC1. В классах BCC2 и ECC2 соответствия при этом возникает множественный запрос на активизацию, означающий, что в момент завершения задачи будет активизирован ее новый экземпляр. Следует подчеркнуть, что для множественного запроса на активизацию выполняется тот же принцип планирования равноприоритетных задач: первой запланирована – первой выполняется. По-видимому, множественный запрос на активизацию может применяться в коммуникационных приложениях, например, когда сообщения, приходящие из сети, обрабатываются задачей, активизирующейся всякий раз, когда поступает новое сообщение. Обработка прерываний. Спецификация требований к обработке прерываний состоит из следующих разделов: обработчики прерываний (например, запросов на прерывания от внешних устройств), селективное управление источниками прерываний, быстрое управление распознаванием прерываний. Обработчики прерываний активизируются при возникновении запросов на прерывание, обычно от внешних устройств, или от самого процессора (например, для обработки исключительных ситуаций). Спецификация определяет три категории обработчиков прерываний. Категория 1 (ISR category 1). Обработчики этой категории не выполняют обращений к ОСРВ. Иными словами, они не изменяют состояния задач и других системных объектов. Обычно такие обработчики выполняются на самых высоких уровнях аппаратных приоритетов и предназначены для обработки событий с самыми короткими сроками выполнения, причем без участия ОСРВ. Категория 2 (ISR category 2). Для обработчиков второй категории ОСРВ автоматически предоставляет необходимые условия для возможности вызова сервисов ОСРВ. Технически это достигается с помощью ключевого слова ISR, поэтому разработчику приложений не надо заботиться о создании контекста, позволяющего обращаться к ОСРВ. Категория 3 (ISR category 3). Обработчики третьей категории являются как бы комбинацией обработчиков первой и второй категорий. Если в процессе выполнения обработчика нужно обратиться к 43 Программные продукты и системы ОСРВ, должен быть выполнен системный вызов EnterISR() для создания нужного контекста, а по окончании обработчика – вызов LeaveISR(), для того чтобы сообщить системе, что обработчик завершен (обработчики категории 2 неявно включают в себя эти вызовы). Практически все вызовы, которые имеет смысл вызывать из обработчиков прерываний, разрешены в обработчиках второй и третьей категории (между обращениями EnterISR/LeaveISR). Например, обработчики прерываний могут активизировать задачу, установить событие для задачи, послать сообщение, установить аларм и т.п. Обработчики прерываний могут быть вложенными, то есть один обработчик может прервать другой. Для этого должны быть созданы соответствующие аппаратные условия. При выполнении вложенных прерываний диспетчеризация задерживается до завершения самого внешнего обработчика. Отметим две проблемы, связанные с использованием обработчиков прерываний. Первая связана с потенциальными трудностями использования локальных переменных в обработчиках, относящихся к категории 3. Проблема состоит в том, что компиляторы обеспечивают выделение памяти под локальные переменные функции-обработчика в самом начале выполнения функции. При вызове EnterISR() стек может быть подменен, и эти локальные переменные становятся неадресуемыми, то есть обращение к ним после вызова EnterISR() приведет к ошибочной адресации. К сожалению, такая ситуация может возникнуть и в том случае, когда разработчик приложения даже не определяет локальные переменные явно. Поскольку компилятор может создать скрытые локальные переменные для выполнения некоторых операций (например, для выполнения битовых операций на 8-битных процессорах). Именно поэтому спецификация указывает на существование такой проблемы, которую можно полностью избежать, лишь отказавшись вовсе от использования обработчиков третьей категории. Вторая проблема связана с вложением обработчика категории 2 или 3 в обработчик первой категории. В таком случае диспетчеризация откладывается на неопределенное время, потому что она не может быть выполнена по завершении вложенного обработчика (поскольку еще есть внешний обработчик), но и не выполняется по завершении внешнего обработчика, потому что обработчик первой категории не взаимодействует с ОС. Чтобы избежать возникновения такой ситуации, спецификация рекомендует правильно назначать приоритеты обработчикам прерываний. Включенное в спецификацию описание селективного управления источниками прерываний подвергается критике в связи с тем, что интерфейсы прикладных программ, поддерживающие запрещение или разрешение распознавания запроса на прерывание от конкретного источника (устройства), не удается специфицировать в платформонезависимом виде, поэтому не достигается переносимость приложений, использующих такие сервисы. Кроме того, при использовании этих сервисов может возникнуть 44 № 4, 2001 г. неограниченное по времени запрещение прерываний, приводящее к аппаратным ошибкам. Например, низкоприоритетная задача, запретившая на короткое время прерывания по приему байта последовательного порта, может быть вытеснена более приоритетными задачами, и тогда «короткое время» затянется на неопределенный срок, что приведет к потере приема следующих байтов. Рабочая группа, разрабатывающая спецификации, согласна с этой критикой. Возможно, функции селективного управления источниками прерываний будут удалены из следующих версий спецификации. Быстрое управление распознаванием прерываний позволяет разрешать и запрещать либо все прерывания процессора, либо только те, которые влияют на работу ОСРВ. Обработка событий. События позволяют расширенной задаче переводить себя в состояние ожидания в том случае, если событие сброшено, и переводить задачу в состояние готовности, когда событие установлено. К сожалению, спецификация не очень четко определяет отображение глобальных событий на биты, используемые задачей, но предполагается, что каждая расширенная задача владеет собственной маской событий, битовыми флагами, которыми можно манипулировать с помощью системных вызовов ОСРВ. Для встроенных приложений, на которые ориентирована спецификация, задачи классов ECC1 и ECC2 приводят к накладным расходам, связанным с использованием выделенной области ОЗУ для стека каждой задачи, и манипулированию битами событий. Поэтому разработчикам приложений следует использовать расширенные задачи с большой осторожностью. Синхронизация с помощью разделяемых ресурсов. Спецификация использует специальный протокол для доступа к ресурсам, защищающим критические секции кода. Этот протокол называется OSEK Priority Ceiling Protocol, хотя он и описывает не собственно Priority Ceiling Protocol, а протокол, имеющий несколько синонимов, например, Highest Locker Protocol или Priority Protect Protocol (в стандарте POSIX). Протокол позволяет добиться исключения тупиков и неограниченной по времени инверсии приоритетов. Это достигается за счет того, что приоритет задачи, запрашивающей разделяемый ресурс, немедленно повышается до порогового значения приоритета ресурса, который вычисляется в процессе конфигурации системы как самый высокий (или выше) приоритет всех задач, имеющих доступ к этому ресурсу. Поэтому при запросе ресурса гарантируется, что никакая другая задача, имеющая доступ к этому ресурсу, не будет переведена в состояние выполнения. Большим достижением OSEK/VDX OS можно считать расширение этого протокола, обычно применяющегося только для задач, на обработчики прерываний для защиты критических секций кода, совместно используемых задачами и обработчиками прерываний. При этом подразумевается, что приоритеты обработчиков прерываний и задач как бы ото- Программные продукты и системы бражаются на одну шкалу и что ОСРВ способна манипулировать запрещением и разрешением уровней прерываний контроллера прерываний. Конечно, такая схема имеет вырожденный характер, если аппаратура поддерживает только один уровень прерываний, но все же может использоваться и в этом случае. Но особенно полезно использование расширения протокола на микропроцессорах, имеющих многоуровневую схему прерываний, например, Motorola 68K. Алармы (управление по таймерам и счетчикам). Спецификация определяет обобщенный объект, называемый алармом, который используется для активизации задач по значениям таймеров и счетчиков, например, измерителями линейных или угловых перемещений. Каждый аларм неявно подразумевает нижележащий счетчик, отсчитывающий значение некоторой величины. Спецификация не определяет программный интерфейс для управления счетчиками, потому что они могут быть полностью реализованы аппаратно, например, с помощью прерываний часов реального времени. Следует отметить, что к одному счетчику могут быть подключены несколько алармов. Спецификация требует, чтобы ОСРВ предоставляла системный таймер. Каждому аларму назначается задача или пара задача-событие. При срабатывании аларма задача активизируется или для нее устанавливается событие. Срабатывание аларма происходит в тот момент, когда значение счетчика достигнет значения установки аларма. Аларм можно установить как на абсолютное значение счетчика, так и на относительное. Также можно установить циклическое значение аларма, организовав таким образом обработку периодических событий. Можно заметить, что алармы обеспечивают очень гибкий и мощный механизм для обработки событий. Однако реализация алармов все же достаточно громоздка, особенно в случае подключения к счетчику нескольких алармов. Передача сообщений. Спецификация OSEK/ VDX OS не содержит описания механизма сообщений, отсылая к спецификации OSEK/VDX COM, в которой специально описаны два класса соответствия сети CCCA и CCCB (CCC – аббревиатура Communication Conformance Class) для локальных сообщений. CCCA описывает небуферизированные сообщения, то есть такие, содержание которых обновляется всякий раз, когда посылается сообщение. CCCB дополнительно определяет буферизированные сообщения, представляющие собой круговою очередь. Сообщения обоих типов имеют фиксированную длину (и размер очереди буферизированных сообщений), определяемую на этапе конфигурирования приложения. При поступлении сообщения может производиться активизация задачи-приемника, установка события для задачи-приемника или может вызываться пользовательская функция. Для сертификации реализации OSEK/VDX OS поставщику ОСРВ достаточно реализовать класс соответствия сети CCCA. № 4, 2001 г. Обработка ошибочных ситуаций и отладка. Для отладки и трассировки приложений спецификация описывает процедуры-ловушки и расширенную информацию об ошибках. Ловушки предоставляются пользователем, но вызываются самой ОС. В случае возникновения системной ошибки вызывается ловушка ошибки, для того чтобы приложение идентифицировало причину ошибки и предприняло корректирующие действия. Две ловушки предназначены для отслеживания переключения контекста задачи, помогая тем самым в трассировке приложения. При старте ОСРВ вызывается стартовая ловушка, в которой можно активизировать задачи, инициализирующие приложение, и выполнить инициализацию аппаратных средств. В случае фатальной ошибки приложение может завершить ОСРВ, при этом вызывается терминальная ловушка, в которой можно выполнить сброс аппаратных средств. Расширенная информация об ошибках предоставляется системными сервисами ОСРВ в том случае, если система статически сконфигурирована для этого. В описании каждой системной функции указывается, какие коды ошибок могут быть возвращены в стандартной и расширенной конфигурациях. Например, в стандартной конфигурации активизация задачи возвращает только код успешного выполнения, а в расширенной конфигурации сообщает о неправильном идентификаторе задачи и об ошибочном множественном запросе на активизацию. Предполагается, что расширенная конфигурация должна использоваться разработчиками приложений на этапе отладки, а отлаженное приложение конфигурируется в стандартном варианте, поскольку расширенная обработка ошибок приводит к существенным накладным расходам, в особенности в части использования процессорного времени. Существует, однако, проблема, связанная с различием временных характеристик исполнения приложения в стандартной и расширенной конфигурациях (разработчикам приложений следует иметь в виду возможные последствия этого различия). Стандарт OSEK/VDX OS отвечает практически всем сегодняшним требованиям разработчиков автомобильных приложений и используется такими концернами, как "Крайслер" и БМВ. Успех спецификации объясняется тесным партнерством заказчиков и поставщиков ОСРВ в разработке спецификации и тщательной проработкой деталей для достижения баланса функциональных возможностей и эффективности реализации, а также для стабильности работы встроенных систем. Список литературы 1. Kopetz H. Real-Time Systems. Design Principles for Distributed Embedded Applications. Kluwer Academic Publishers. MA, 1997. 2. OSEK/VDX Operating System, Version 2.1 revision 1, 13. November 2000. 3. OSEK/VDX Communication, Version 2.2.2, 18th December 2000. 45