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

Средства построения мультипроцессорных систем. 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.

2.2. QNX Neutrino RTOS

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

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

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

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

Обладая вытесняющим микроядром и планировщиком с приоритетным обслуживанием, QNX Neutrino RTOS способна быстро и с высокой предсказуемостью реагировать на события реального времени. Высокоприоритетные потоки обрабатывают дедлайны своевременно даже при большой загрузке системы (см. рис. 2)

Рис. 2. Производительность реального времени QNX Neutrino RTOS.

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

2.3. RTEMS

RTEMS (Real-Time Executive for Multiprocessor Systems) – это некоммерческая операционная система реального времени для глубоко встраиваемых систем [RTEMS]. Разработчик системы компания OAR (On-Line Applications Research Corporation, США). Система была создана по заказу министерства обороны США для использования в системах управления ракетными комплексами. Система разрабатывается для многопроцессорных систем на основе открытого исходного кода в противовес аналогичным системам с закрытым кодом. Система рассчитана на платформы MS-Windows и Unix (GNU/Linux, FreeBSD, Solaris, MacOS X).

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

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

Ядро RTEMS отвечает за управление основной памятью компьютера и виртуальной памятью выполняемых процессов, за управление процессором и планирование распределения процессорных ресурсов между совместно выполняемыми процессами, за управление внешними устройствами и, наконец, за обеспечение базовых средств синхронизации и взаимодействия процессов. При этом ядро использует соответствующие менеджеры. В состав RTEMS входит набор следующих менеджеров: инициализации, задач, прерываний, часов реального времени, таймера, семафоров, сообщений, событий, сигналов, разделов, регионов, двухпортовой памяти, ввода/вывода, неисправимых ошибок, монотонной частоты, расширений пользователя, многопроцессорности. Привязка ОСРВ к аппаратуре производится с помощью специальной библиотеки подпрограмм BSP (board support package) и специализированных подпрограмм для различных архитектур. В состав BSP входят программа инициализации аппаратуры и драйверы устройств. Поддержка в RTEMS мультипроцессорных систем позволяет использовать ее для управления как однородными, так и неоднородными системами Ядро RTEMS автоматически учитывает различия в архитектуре используемых процессоров, выполняя в случае необходимости перестановку байтов и другие процедуры. Это позволяет осуществлять переход на другое семейство процессоров без значительных изменений системы.

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

В ОСРВ RTEMS реализуются следующие виды межпроцессорного взаимодействия:

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

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

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

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

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

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

Менеджер задач. Обеспечивает полный набор функций для создания, удаления и управления задачами. С точки зрения RTEMS, задачей является наименьшая последовательность команд, которая может самостоятельно конкурировать за использование системных ресурсов. Каждой задаче соответствует блок контроля задачи TCB (Task Control Block). Этот блок является структурой, которая содержит всю информацию, относящуюся к выполнению задачи. В процессе инициализации RTEMS выделяет TCB для каждой задачи, имеющейся в системе. Элементы TCB изменяются в соответствии с системными вызовами, которые выполняются приложением в ответ на внешние запросы. Блок TCB – это единственная внутренняя структура данных RTEMS, доступная приложению через дополнительные процедуры пользователя. При переключении задач в TCB сохраняется контекст задачи. При возвращении управления задаче ее контекст восстанавливается. При перезапуске задачи исходный контекст задачи восстанавливается в соответствии со стартовым контекстом, хранящемся в TCB. Задача может находиться в одном из пяти состояний: выполнение; готовность к выполнению (управление может быть передано задаче); остановка (задача заблокирована); спящий режим (созданная, но не запущенная задача); отсутствие задачи (задача не создана или удалена).

Ядро реального времени RTEMS поддерживает 255 уровней приоритетов. Чем больше значение приоритета, тем более привилегированной является задача. Количество задач, имеющих одинаковый приоритет, не ограничено. Каждая задача всегда имеет какой-либо уровень приоритета, начальное значение которого присваивается при создании задачи и в дальнейшем может быть изменено. Режим выполнения задачи определяется следующими параметрами: вытесняемость; обработка асинхронных запросов ASR (Asynchronous Signal Request); квантование времени; уровень прерывания. Эти параметры используются для распределения процессорного времени и изменения контекста задачи. Они задаются пользователем при компиляции системы.

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

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

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

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

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