Глава 1. Виды и стандарты ОСРВ.

Оглавление

Предисловие………………………………………………….………………….5

 

Глава 1 Виды и стандарты ОСРВ………………………….……………...…7

1.1 Общие характеристики ОСРВ………………………….……...…..7

1.2 Технические параметры ОСРВ…………………….……….…..…8

1.3 Особенности систем реального времени……….…………......10

1.4 Распределение задач по времени (планирование, выполнение)…………………………………………….….……..…11

 

2.ОС реального времени……………………………………….…………....13

2.1 Стандарты ОСРВ……………………………….………………....13

2.1.1 PO SIX…………………………………………….…………...15

2.1.2 DO-178B……....………………………....….…………………18

2.1.3 ARINC-653…………………………………….…………...….19

2.1.4 OSEK………………………………………………….………..19

 

3. ОСРВ……………………………………………………………………….…21

3.1. Краткие характеристики различных ОСРВ………………..…21

3.1.1. VxWorks………………………………………………………21

3.1.2. QNX Neutrino RTOS………………………………………...28

3.1.3. RTEMS………………………………………………………..31

3.1.4. ChorusOS…………………………………………………….41

3.1.5. LynxOS………………………………………………………..45

3.1.6. pSOS………………………………………………………….46

3.1.7. Microware OS-9……………………………………………...48

3.2. Windows NT – ОСРВ?.............................................................50

3.2.1. RTX для Windows NT………………………………………52

3.2.2. INtime………………………………………………………….57

3.2.3. Microsoft Windows Embedded……………………….........58

 

Глава 2 Аппаратная реализация ОСРВ……………………………………61

1. Аппаратурная среда……………………………………………........61

1.1. Типы компьютеров, применяемых в СРВ……………..61

1.2. “Обычные” компьютеры…………………………………..61

1.3. Промышленные компьютеры……………………………62

1.4 Рабочие станции…………………………………..………..67

1.5 Кросс-системы……………………………………..………..69

2. Устройство связи с объектом…………………………………………….81

3. Методы и средства обработки асинхронных событий……….…..…..86

 

Глава 3 Многопоточность ОСРВ……………………………………………87

1. Концепция процесса многозадачности……………………………..87

2. Ядро операционной системы реального времени………………..91

 

Глава 4 Языки программирования и работа с файлами в ОСРВ……103

1. Языки программирования систем реального времени…………104

1.1. Ada………………………………………………………………...104

1.2. Модула-2………………………………………………………...107

1.3. Oz…………………………………………………………………110

2. Асинхронный файловый ввод-вывод……………………………...113

 

Библиография………………………………………………………………..121

Предисловие.

Системы реального времени часто используются как управляющие устройства для специальных приложений, - например, для научных экспериментов; в медицинских системах, связанных с изображениями; системах управления в промышленности; системах отображения (display); системах управления космическими полетами, АЭС и др. Для таких систем характерно наличие и выполнение четко определенных временных ограничений (время реакции – response time; время наработки на отказ и др.).

Различаются системы реального времени видов hard real-time и soft real-time.

Hard real-time – системы – системы реального времени, в которых при нарушении временных ограничений может возникнуть критическая ошибка (отказ) управляемого ею объекта. Примеры: система управления двигателем автомобиля; система управления кардиостимулятором. В таких системах вторичная память ограничена или отсутствует; данные хранятся в оперативной памяти (RAM) или постоянном запоминающем устройстве (ПЗУ, ROM). При использовании таких систем возможны конфликты с системами разделения времени, не имеющие места для ОС общего назначения. Выражаясь более простым языком, при работе подобных систем не допускаются прерывания; все необходимые данные для основного цикла работы системы должны предварительно быть загружены в память; процесс, выполняющий код такой системы, не должен подвергаться откачке на диск. ОС для таких систем обычно упрощены, вместо виртуальной памяти выделяется физическая, все другие виды виртуализации ресурсов исключены. Популярной практикой разработки ОС реального времени является практика разработки таких ОС на основе открытых исходных кодов ОС общего назначения путем " отсечения всего лишнего". Однако при этом следует соблюдать осторожность. Автору приходилось консультировать разработчиков системы реального времени для " Эльбруса", которые использовали для своей системы низкоуровневую процедуру выделения физической памяти, но не учли ее возможных конфликтов с общей системой виртуальной памяти ОС Эльбрус; в результате выделяемая память иногда " портилась" … в результате изменения связующей информации в списке областей свободной памяти, который использовался механизмом виртуальной памяти " Эльбруса".

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

 

Глава 1. Виды и стандарты ОСРВ.

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

ОСРВ – это операционные системы, для которых характерно:

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

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

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

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

2. Гарантированное время отклика.

3. Ограниченность ресурсов памяти.
Данная характеристика определяется аппаратными особенностями ПК, на котором функционируют СРВ. Они подробно рассмотрены в п.2 данного пособия. ОС часто работает на бездисковом компьютере и осуществляет начальную загрузку из ПЗУ, часть системы хранится в сжатом виде и подгружается по мере необходимости; может исполнять код как в ОЗУ, так и в ПЗУ и копировать себя из медленного ПЗУ в быстрое ОЗУ при наличии свободного места.

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

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

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

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

 

Технические параметры ОСРВ

Перечислим основные технические параметры, которые должна обеспечивать ОС реального времени:

• Время реакции системы на прерывание (interrupt latency – латентная задержка прерывания) - интервал времени от события на объекте до выполнения первой инструкции в программе обработки этого события.

Рис.1 Время реакции различных систем на прерывание

• Время реакции задачи (task response) - интервал времени от момента возникновения физического прерывания до начала выполнения первой инструкции задачи пользователя, которой предназначено прерывание.
• Время переключения контекста (context switch) - интервал времени от момента окончания выполнения последней инструкции одного процесса (потока) до момента начала выполнения первой инструкции следующего процесса (потока). Этот интервал определяет, как часто каждый из активных процессов может получать управление при заданных параметрах квантования времени.

Рис. 2 Время переключения контекста

• Задержка диспетчеризации (scheduling latency) - интервал времени от момента окончания выполнения последней инструкции пользовательского обработчика прерываний до момента выполнения первой инструкции процесса, перешедшего в активное состояние из-за этого прерывания;
• Максимальное время исполнения каждого системного вызова. Оно должно быть предсказуемым и не зависеть от количества объектов в системе;
• Максимальное время, на которое модули ОС и драйверы могут блокировать прерывания;
• Неустойчивость таймера (timer jitter) - разница во времени срабатывания таймера с фиксированной длительностью.
• Размеры ОС.

 

Стандарты ОСРВ

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

• Поддержка и организация выполнения всех задач;
• Управление прерываниями;
• Реализация взаимодействия процессов в системе;
• Запуск задач в назначенные моменты времени.

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

Табл.1 Основные отличия операционных систем реального времени от универсальных ОС

Универсальные ОС ОС реального времени Назначение • эффективное управление ресурсами, • предоставление удобного интерфейса; • создание СРВ, • управление СРВ • обеспечение функционирования СРВ Состав Набор готовых приложений Инструмент для создания аппаратно-программного комплекса СР Пользователи Пользователи приложений Проектировщики, разработчики

 

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

Наиболее ранним и распространенным стандартом ОСРВ является стандарт 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 и большую востребованность обновлений стандартизации для ОСРВ, заметного продвижения в этом направлении не наблюдается.

Некоторые наиболее успешные компании в области систем реального времени объявляют о своем решении принять в качестве стандарта спецификации одной из своих продвинутых ОСРВ. Так поступила компания TRON (the RTOS Nucleus), которая в 1987г. выпустила в свет первые ITRON спецификации – ITRON1. Далее в 1989г. она разработала и выпустила спецификации µITRON для 8- и 16- битовых микроконтроллеров, а также спецификации ITRON2 для 32-битовых процессоров. ОСРВ ITRON описывается ниже в соответствующем разделе. Этот стандарт является очень распространенным в Японии.

Военная и аэрокосмическая отрасли предъявляют жесткие требования к вычислительным средствам, влияющим на степень безопасности целевой системы. В настоящее время имеются следующие стандарты для ОСРВ в авиации – стандарт DO-178B и стандарт ARINC-653. Поскольку эти стандарты разработаны в США, стоит отметить еще европейский стандарт ED-12B, который является аналогом DO-178B.

Распространенным также является стандарт OSEK/VDX [OSEK], который первоначально развивался для систем автомобильной индустрии.

POSIX

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

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

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

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

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

Стандарт 1003.1b (Realtime Extensions) содержит расширения реального времени – сигналы реального времени, планирование выполнения (с учетом приоритетов, циклическое планирование), таймеры, синхронный и асинхронный ввод/вывод, ввод/вывод с приоритетами, синхронизация файлов, блокировка памяти, разделяемая память, передача сообщений, семафоры. Чтобы стать POSIX-комплиантной, ОС должна реализовать не менее 32 уровней приоритетов. POSIX определяет три политики планирования обработки процессов:

• SCHED_FIFO – процессы обрабатываются в режиме FIFO и выполняются до завершения,
• SCHED_RR – round robin – каждому процессу выделяется квант времени,
• SCHED_OTHER – произвольная реализационно-зависимая политика, которая не переносима на другие платформы.

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

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

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

Стандарт 1003.2h касается сервисов, отвечающих за работоспособность системы.

Табл. 2. Семейство стандартов POSIX

Стандарт	Краткое описание
POSIX.0	Введение в стандарт открытых систем. Данный документ не является стандартом в чистом виде, а представляет собой рекомендации и краткий обзор технологий
POSIX.1	Система API (язык Си)
POSIX.2	Оболочки и утилиты (одобренные IEEE)
POSIX.3	Тестирование и верификацция
POSIX.4	Задачи реального времени и потоки
POSIX.5	Использование языка ADA применительно к стандарту POSIX.1
POSIX.6	Системная безопасность
POSIX.7	Администрирование системы
POSIX.8	Сети. «Прозрачный» доступ к файлам. Связь системы с протоколо-зависимыми приложениями. Вызов удаленных процедур
POSIX.9	Использование языка FORTRAN применимо к стандарту POSIX.1
POSIX.10	Профиль прикладной среды организации вычислений на супер-ЭВМ (APE)
POSIX.11	Обработка транзакции AEP
POSIX.12	Графический интерфейс пользователя (GUI)

 

DO-178B

Стандарт DO-178B, создан Радиотехнической комиссией по аэронавтике (RTCA, Radio Technical Commission for Aeronautics) для разработки ПО бортовых авиационных систем [DO178B]. Первая его версия была принята в 1982 г., вторая (DO-178A) - в 1985-м, текущая DO-178B - в 1992 г. Готовится принятие новой версии, DO-178C. Стандартом предусмотрено пять уровней серьезности отказа, и для каждого из них определен набор требований к программному обеспечению, которые должны гарантировать работоспособность всей системы в целом при возникновении отказов данного уровня серьезности.

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

• А (катастрофический),
• В (опасный),
• С (существенный),
• D (несущественный)
• Е (не влияющий).

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

ARINC-653

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

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 ошибочно воспринимается как стандарт ОСРВ. Хотя ОС и есть большая порция данного стандарта, мощность его состоит в интеграции всех его компонент.

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

ОСРВ

VxWorks

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

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

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

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

Ядро VxWorks обладает следующими параметрами:

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

В VxWorks обеспечивается как основанный на POSIX, так и собственный механизмы планирования (wind scheduling). Оба варианта включают вытесняющее и циклическое планирование. Различие между ними состоит в том, что wind scheduling применяется на системном базисе, в то время как алгоритмы POSIX-планирования применяются на базисе процесс-за-процессом.

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

Чтобы достичь быстрой обработки внешних прерываний, программы обработки прерываний (ISRs – interrupt service routines) в VxWorks выполняются в специальном контексте вне контекстов потоков, что позволяет выиграть время, которое обычно тратится на переключение контекстов. Следует отметить, что C-функция, которую пользователь присоединяет к вектору прерывания, на самом деле не является фактической ISR. Прерывания не могут непосредственно обращаться к C-функциям. Адрес ISR запоминается в таблице векторов прерываний, которая вызывается аппаратно. ISR выполняет некую начальную обработку (сохранение регистров и подготовку стека), а затем вызывается C-функция, которая была присоединена пользователем.

Рис.4 Иерархическая структура VxWork

VSPWorks [VSPWorks] – это весьма популярная и достаточно мощная ОС на основе VxWorks. VSPWorks спроектирована специально для систем, основанных на DSP. Она обеспечивает многозадачный режим с приоритетами и поддержку быстрых прерываний на процессорах DSP и ASIC. ОСРВ VSPWorks следует модели единственного виртуального процессора, что значительно упрощает распределение приложений в многопроцессорной системе, сохраняя при этом производительность жесткого реального времени. VSPWorks является модульной и масштабируемой.

ОСРВ VSPWorks обладает многослойной структурой, что служит хорошей основой для абстрагирования и переносимости. Центром системы служит сильно оптимизированное наноядро (nanokernel), которое способно управлять совокупностью процессов. Ниже наноядра находятся программы, обслуживающие прерывания, выше наноядра располагается микроядро, которое управляет многозадачным режимом с приоритетами C/C++ задач.Управление прерываниями имеет два уровня. Нижний уровень (уровень 1) используется для обработки аппаратных прерываний. Во время обработки таких прерываний все остальные прерывания блокируются. Код, выполняющийся на этом уровне, написан на языке ассемблера, и ответственность за сохранение соответствующих регистров в стеке ложится на программиста. На этом уровне может быть обработано прерывание, которое требует малого времени для обработки. Если обработка прерывания является более сложной и требует большего времени, то прерывание обрабатывается на более высоком уровне (уровень 2), где разрешено прерывание прерывания и, таким образом, они могут быть вложенными. Переход на более высокий уровень прерываний происходит по системному вызову.

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

Микроядро находится на уровне 4. Микроядро написано на языке C и имеет свыше 100 сервисов. Обработка задач на этом уровне ведется в режиме приоритетного прерывания, и планирование управляется приоритетами.

Сетевые средства. VxWorks поддерживает все сетевые средства, стандартные для UNIX: TCP/zero-copyTCP/UDP/ICMP/IP/ARP, SLIP/CSLIP/PPP, Sockets, telnet/rlogin/rpc/rsh, ftp/tftp/bootp, NFS (Network File System) (клиент и сервер). В сетевые средства для VxWorks входят также функции, необходимые при разработке устройств, подключаемых к Internet: IP multicasting уровня 0, 1 или 2; long fat pipe; CIDR (Classless Inter-Domain Routing); DHCP (Dynamic Host Configuration Protocol) в конфигурациях server, client и relay agent; DNS client (Domain Naming System); SNTP (Simple Network Time Protocol). VxWorks поддерживает протоколы маршрутизации RIPv1/RIPv2 (Routing Information Protocol), а также OSPF (Open Shortest Path First) версии 2. Протокол RIP входит в стандартную поставку VxWorks, OSPF поставляется как дополнительный продукт. SNMP-агент для VxWorks поддерживает протокол SNMP (Simple Network Management Protocol) как версии v1, так и v2c. MIB (Management Information Base) компилятор поддерживает объекты MIB-II и расширения. STREAMS – стандартный интерфейс для подключения переносимых сетевых протоколов к операционным системам. В среде VxWorks можно инсталлировать любой протокол, имеющий STREAMS-реализацию: как стандартный (Novell SPX/IPX, Decnet, AppleTalk, SNA и т.п.), так и специализированный. VxWorks поддерживает STREAMS версии UNIX System V.4.

Графические пакеты и встроенный Интернет. Графические приложения для встраиваемых компьютеров с ОСРВ VxWorks могут быть разработаны как на языке С/С++, так и на языках Java и HTML. Для разработки графических пользовательских интерфейсов (GUI) на языке C++ поставляется программный продукт Zinc for VxWorks, для разработки на языке Java – PersonalJWorks и для разработки на языке HTML – HTMLWorks/eNavigator. Все три GUI для VxWorks используют один и тот же универсальный API к графической аппаратуре (графическому контроллеру, фрэйм-буферу и устройству ввода), который называется UGL (Universal Graphics Library). UGL – это набор графических 2D примитивов, драйверы популярных графических контроллеров и средства разработки собственных пользовательских графических драйверов. UGL входит в состав каждого GUI-продукта и поставляется в исходных текстах.

Zinc for VxWorks – это C++ API, предоставляющий широкий набор графических объектов с задаваемыми пользователем параметрами. Для разработки GUI используется Zinc Designer – WYSIWYG-редактор, который входит в комплект поставки. Графический интерфейс может быть разработан на языке Java с использованием стандартного инструментария pAWT (Abstract Windowing Toolkit), входящего в состав PersonalJWorks. Для разработки GUI используется любой инструментарий разработки Java-приложений. Пользовательский интерфейс может быть разработан с использованием графических возможностей языка HTML (фреймы, изображения, таблицы, формы) и динамических возможностей JavaScript. HTMLWorks – это интерпретатор HTML/JavaScript-страниц, которые могут находиться в постоянной памяти или быть загружены по сети. Для разработки GUI используется любой инструментарий web-дизайна. Если встраиваемый компьютер с HTML GUI должен уметь выполнять web-серфинг, то совместно с HTMLWorks может быть использован браузер для встраиваемых приложений eNavigator.

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

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

Промежуточное ПО (middleware). Модель компонентных объектов COM (Component Object Model) и ее расширение для распределенных систем DCOM (Distributed COM) являются стандартными интерфейсами обмена между приложениями для Windows. VxDCOM – DCOM для операционной системы VxWorks – это первая реализация модели распределенных компонентных объектов для систем реального времени. Теперь нет необходимости в разработке специализированных драйверов ввода/вывода при интеграции нижнего и верхних уровней распределенной системы управления. VxDCOM поддерживает также OPC-интерфейсы (OLE for Process Control), что позволяет разрабатывать OPC-серверы для встраиваемых систем, работающих под управлением ОСРВ VxWorks.

Файловая система для флэш-памяти. Файловая система TrueFFS предназначена для эмуляции жесткого диска, работающего под управлением файловых систем VxWorks: DOS-FS и NFS (Network File System). TrueFFS удовлетворяет стандарту PCMCIA FTL (Flash Translation Level) и поддерживает PC-cards, MiniatureCards и микросхемы флэш-памяти Intel 28F0xx, AMD 29F0xx, и Samsung 29Vxx000.

 

QNX Neutrino RTOS

Операционная система QNX Neutrino Realtime Operating System (RTOS) [QNXNeutrino] корпорации QNX Software Systems является микроядерной операционной системой, которая обеспечивает многозадачный режим с приоритетами. QNX Neutrino RTOS имеет клиент-серверную архитектуру. В среде QNX Neutrino каждый драйвер, приложение, протокол и файловая система выполняются вне ядра, в защищенном адресном пространстве. В случае сбоя любого компонента он может автоматически перезапуститься без влияния на другие компоненты или ядро. Хотя система QNX является конфигурируемой, т.е. отдельные модули можно загружать статически или динамически, нельзя сказать, что она использует подход, основанный на компонентах. Все модули полагаются на базовое ядро и спроектированы таким образом, что не могут использоваться в других средах[2].

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

Ядро QNX Neutrino RTOS выполняется на уровне 0, управляющие программы и драйверы устройств выполняются на уровнях 1 и 2, совершая операции ввода/вывода. Приложения выполняются на уровне 3.

Рис.5 Структура ядра QNX

 

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

123456789Следующая ⇒

Поделиться: