Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Федеральное агентство по образованию
Кафедра автоматизированных систем управления
Системы реального времени
Введение
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, их потенциал и выполняемые задачи.
Основные требования к коммерческим операционным системам реального времени (RTOS), принятым для эксплуатации (особенно это касается авиации, наземного и водного транспорта и опасных технологических процессов), заключаются в следующем:
– требования «жесткого» реального времени; детерминированное поведение при различных нагрузках на систему, необходимое в ответственных приложениях и системах повышенной готовности;
– высокая «живучесть», чтобы при отказе какой-либо части программного обеспечения другая часть продолжала нормально функционировать;
– строгие требования по качеству, что подразумевает соответствие различным отраслевым, национальным и международным стандартам;
– требования по надежности; вероятность сбоя в программе должна быть очень маленькой;
– требования по безопасности данных; в системе должны быть предусмотрены средства защиты наиболее важной информации.
Перечислим основные документы, регламентирующие требования к операционным системам реального времени.
Стандарт DO-178 (Software Consideration in Airborne Systems and Equipment Certification) – стандарт, регламентирующий требования к операционным системам реального времени, разработанный и поддерживаемый ассоциацией Radio Technical Commission for Aeronautics (RTCA). Стандартом определено пять уровней серьезности отказа, для каждого из которых указывается набор требований к программному обеспечению, призванных гарантировать работоспособность всей системы в целом при возникновении отказов данного уровня:
– уровень А – защита от сбоев, приводящих к катастрофическим последствиям;
– уровень В – защита от сбоев, приводящих к опасным последствиям;
– уровень С – защита от сбоев, приводящих к большим последствиям;
– уровень D – защита от сбоев, приводящих к минимальным последствиям;
– уровень Е – защита от сбоев, не приводящих ни к каким последствиям.
Стандарт ED-12 B – стандарт, регламентирующий требования к операционным системам реального времени, европейский аналог DO-178B, определяющийся ассоциацией The European organization for civil aviation equipment.
RTCA DO-248B (Final Annual Report For Clarification Of DO-178 В ) – пояснительный документ к DO-178B. Его основные темы включают такие разделы, как ранее разработанное программное обеспечение, коммерческие программные продукты, процессы верификации, исторические справки, автоматизированные средства и др.
Стандарт DO-254 (Design Assurance Guidance for Airborne Electronic Hardware) – разработанный и поддерживаемый ассоциацией RTCA стандарт, регламентирующий процессы жизненного цикла аппаратных средств и описывающий пути обеспечения нужных свойств изделий с целью их сертификации в соответствии с предъявляемыми требованиями.
ARINC 653 (Avionics Application Software Standard Interface) – стандарт, разработанный компанией ARINC в 1997 году и определяющий универсальный программный интерфейс APEX (APplication/EXecutive) между операционной системой бортового компьютера и прикладным программным обеспечением. Требования интерфейса определяются таким образом, чтобы разрешить прикладным программам контролировать диспетчеризацию, связь и состояние внутренних обрабатываемых элементов. В качестве одного из основных требований для операционных систем реального времени ARINC 653 вводит архитектуру изолированных (partitioning) виртуальных машин.
Общие критерии для оценки секретности информационных технологий (Common Criteria for Information Technology Security Evaluation) – набор требований и условий секретности (www.commoncriteria.org), одобренный Агентством национальной безопасности США и Национальным институтом стандартов и технологий США, а также соответствующими органами в других странах (в данный момент еще 13 стран, кроме США). В 1999 году «Общие критерии» получили статус Международного стандарта ISO 15408.
MILS (Multiple Independent Levels of Security/ Safety) – система стандартов, которая развивается усилиями заинтересованных организаций, таких как Исследовательская лаборатория ВВС США, компания Lockheed Martin, Агентство национальной безопасности США и др., и которая делает возможной математическую верификацию программного ядра системы путем уменьшения функциональности за счет предъявления к системам четырех обязательных групп требований (Information Flow, Data Isolation, Period Processing, Damage Limitation). MILS-архитектура представляет собой систему с изолированными разделами, каждый из которых включает ядро, программное обеспечение промежуточного слоя и приложение (рис. 2.1).
Рис. 2.1. MILS-архитектура
POSIX (Portable Operating System interface for unIX) – стандарт, определяющий переносимый интерфейс операционной системы на уровне исходных текстов. Основная спецификация разработана как IEEE 1003.1 и одобрена как Международный стандарт ISO/IEC 9945-1:1990. С точки зрения операционных систем реального времени наибольший интерес представляют три стандарта: 1003.1а (OS Definition), 1003.1b (Realtime Extensions) и 1003.1c (Threads).
Системы виртуальных машин
Многозадачность в операционных системах
Многозада́чность (англ. multitasking) - свойство операционной системы или среды программирования обеспечивать возможность параллельной (или псевдопараллельной) обработки нескольких процессов. Истинная многозадачность операционной системы возможна только в распределённых вычислительных системах.
Существует 2 типа многозадачности:
Процессная многозадачность (основанная на процессах - одновременно выполняющихся программах). Здесь программа - наименьший элемент кода, которым может управлять планировщик операционной системы. Более известна большинству пользователей (работа в текстовом редакторе и прослушивание музыки).
Поточная многозадачность (основанная на потоках). Наименьший элемент управляемого кода - поток (одна программа может выполнять 2 и более задачи одновременно).
СВМ (VM, и её ранняя версия CP/CMS) - первая система, в которой была реализована технология виртуальных машин. Виртуализация в СВМ была последовательной и полной, в частности, на виртуальной машине можно было запустить другую копию системы СВМ, и так далее. Более того, запуск СВМ на виртуальной машине СВМ был рекомендованным методом генерации новой версии системы для установки. В частности, это означало, что любое реальное устройство ЭВМ могло быть тем или иным методом представлено в виде виртуального устройства на виртуальной машине. До сих пор ни одна другая реализация виртуальных машин не обладает таким свойством.
Открытая система - это система, которая состоит из компонентов, взаимодействующих друг с другом через стандартные интерфейсы". Это определение, данное одним из авторов упомянутого руководства Жаном-Мишелем Корну, подчеркивает системный аспект (структуру открытой системы).
"Исчерпывающий и согласованный набор международных стандартов информационных технологий и профилей функциональных стандартов, которые специфицируют интерфейсы, службы и поддерживающие форматы, чтобы обеспечить интероперабельность и мобильность приложений, данных и персонала". Это определение, данное специалистами IЕЕЕ, подчеркивает аспект среды, которую предоставляет открытая система для ее использования (внешнее описание открытой системы).
Вероятно, одно достаточно полное и общепринятое определение открытых систем еще не сформировалось. Однако сказанного выше уже достаточно, чтобы можно было рассмотреть общие свойства открытых систем и выяснить существо связанных с ними проблем.
Общие свойства открытых систем обычно формируются следующим образом:
расширяемость/масштабируемость -extensibility/scalability,
мобильность (переносимость) - portalility,
интероперабельность (способность к взаимодействию с другими системами) - interoperability,
дружественность к пользователю, в т.ч. - легкая управляемость - driveability.
Большие различия в спецификациях ОСРВ и огромное количество существующих микроконтроллеров выдвигают на передний план проблему стандартизации в области систем реального времени.
Наиболее ранним и распространенным стандартом ОСРВ является стандарт 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"а, он затрагивает основополагающие абстракции операционных систем, а расширения реального времени применимы ко всем ОСРВ.
Модель OSI, как следует из ее названия (Open System Interconnection), описывает взаимосвязи открытых систем . Что же такое открытая система?
В широком смысле открытой системой может быть названа любая система (компьютер, вычислительная сеть, ОС, программный пакет, другие аппаратные и программные продукты), построенная в соответствии с открытыми спецификациями .
Напомним, что под термином "спецификация" (в вычислительной технике) понимают формализованное описание аппаратных или программных компонентов, способов их функционирования, взаимодействия с другими компонентами, условий эксплуатации, ограничений и особых характеристик. Понятно, что не всякая спецификация является стандартом .
Использование при разработке систем открытых спецификаций позволяет третьим сторонам разрабатывать для этих систем различные аппаратные или программные средства расширения и модификации, а также создавать программно-аппаратные комплексы из продуктов разных производителей.
Для реальных систем полная открытость является недостижимым идеалом. Как правило, даже в системах, называемых открытыми, этому определению соответствуют лишь некоторые части, поддерживающие внешние интерфейсы. Например, открытость семейства операционных систем Unix заключается, кроме всего прочего, в наличии стандартизованного программного интерфейса между ядром и приложениями, что позволяет легко переносить приложения из среды одной версии Unix в среду другой версии. Еще одним примером частичной открытости является применение в достаточно закрытой операционной системе Novell NetWare открытого интерфейса Open Driver Interface (ODI) для включения в систему драйверов сетевых адаптеров производства независимых компаний. Чем больше открытых спецификаций использовано при разработке системы, тем более открытой она является.
Модель OSI касается только одного аспекта открытости, а именно открытости средств взаимодействия устройств, связанных в вычислительную сеть. Здесь под открытой системой понимается сетевое устройство, готовое взаимодействовать с другими сетевыми устройствами с использованием стандартных правил, определяющих формат, содержание и значение принимаемых и отправляемых сообщений.
Если две сети построены с соблюдением принципов открытости, то это дает следующие преимущества:
возможность построения сети из аппаратных и программных средств различных производителей, придерживающихся одного и того же стандарта;
возможность безболезненной замены одних компонентов сети другими, что позволяет сети развиваться с минимальными затратами;
возможность легкого сопряжения одной сети с другой;
простота освоения и обслуживания сети.
Ярким примером открытой системы является сеть Internet. Эта сеть развивалась в полном соответствии с требованиями, предъявляемыми к открытым системам. В разработке ее стандартов принимали участие тысячи специалистов-пользователей из различных университетов, научных организаций и фирм-производителей вычислительной аппаратуры и программного обеспечения, работающих в разных странах. Само название стандартов, определяющих работу Internet - Request For Comments (RFC, что можно перевести как "запрос на комментарии", - говорит об открытом характере принимаемых стандартов. В результате сеть Internet объединила в себе разнообразное оборудование и программное обеспечение огромного количества сетей, разбросанных по всему миру.
