Операционные системы реального времени для 32-разрядных микропроцессоров

Сергей Золотарев

Рассматривается текущее состояние операционных систем реального времени для 32-разрядных микропроцессоров и основные направления их развития на примере наиболее известных в этом сегменте операционных систем: VxWorks, LynxOS, QNX Neutrino, Integrity, Nucleus Plus и CsLeos.

Круг рассматриваемых операционных систем

Вначале остановимся на определении и особенностях операционных систем реального времени (ОСРВ). Стандарт POSIX 1003.1 даёт такое определение: "Реальное время в операционных системах - это способность операционной системы обеспечить требуемый уровень сервиса в определённый промежуток времени". Как правило, применение ОСРВ связано с аппаратурой, объектом и событиями, происходящими на нём [1]. По сравнению с ОС общего назначения это обуславливает коренные отличия в структуре системы, в функциях ядра и в построении системы ввода-вывода. И при этом пользовательский интерфейс ОСРВ может быть похож на интерфейс ОС общего назначения. Часто различают ОСРВ жёсткого (ОСЖРВ) или мягкого (ОСМРВ) реального времени. ОСЖРВ не допускают никаких задержек реакции системы ни при каких условиях, т.к. результаты могут оказаться бесполезными в случае опоздания либо может произойти катастрофа в случае задержки реакции. Примеры ОСЖРВ - системы управления оружием или технологическими процессами в промышленности. ОСМРВ характеризуются тем, что задержка реакции не критична, хотя и может привести к увеличению стоимости результатов, снижению производительности или качества системы в целом. Пример - работа сети. Если система не успела обработать очередной принятый пакет, это приведёт к тайм-ауту на передающей стороне и повторной посылке. Данные при этом не теряются, но производительность сети снижается.

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

Ещё одной важной особенностью большинства современных ОСРВ является ихмногоплатформенность -возможность работы на аппаратных средствах с различной процессорной архитектурой. Если раньше многие ОСРВ (например, QNX2 или QNX4) разрабатывались специально под какую-либо одну процессорную архитектуру (например, х86) и в значительной степени базировались на особенностях именно этой платформы, то сейчас практически все наиболее популярные ОСРВ являются многоплатформенными (за исключением CsLeos). Стандартный набор процессорных архитектур, поддерживаемых ОСРВ, - x86, PowerPC, ARM (включая XScale), MIPS, SH-4. Однако на практике выявились лидеры среди ОСРВ для конкретных процессорных архитектур. В частности, для x86 -это QNX (особенно в России), для PowerPC - LynxOS.

Первые коммерческие ОСРВ получили широкое распространение одновременно с появлением персональных компьютеров в начале 80-х годов XX в. В 90-е годы регулярно публиковались сводные таблицы по ОСРВ (www.dspconsulting.com/rtos.html), и в частности журналом Real-Time Magazine (www.omimo.be/maga-zine/bakissue.htm). Довольно хороший перечень ОСРВ дан на сайте электронного журнала Dedicated Systems (www.realtime-info.be/encyc/buy-ersguide/products/Dir1048.html). В настоящее время из более чем сотни ОСРВ, разработанных в разное время, широкое распространение получили лишь около двадцати [3], список которых приведён в табл. 1. В этой таблице представлены лишь "самостоятельные" ОСРВ и не рассматриваются ОСРВ, являющиеся расширением какой-либо универсальной ОС. В частности, не рассматриваются расширения реального времени Linux, такие как RTAI Linux (www.rtai.org) или KURT (www.ittc.ku.edu/kurt/), и расширения реального времени Windows, такие как RTX (www.ardence.com) или CeWin (www.kuka-controls.com). Кроме того, не рассматриваются специализированные системы ОСРВ для сигнальных процессоров и микропроцессоров с разрядностью, отличной от 32 бит.

Таблица 1. Список наиболее распространённых ОСРВ

^*Добавлено в таблицу автором.

С точностью до МИКРОСЕКУНДЫ

В теории и на практике используются несколько параметров, описывающих поведение ОСРВ с точки зрения характеристик реального времени [4]. Дадим описание этих параметров: запаздывание прерываний (interrupt latency) - время от момента возникновения физического прерывания до начала выполнения

• первой инструкции обработчика прерываний (ISR), написанной пользователем;
  
• запаздывание диспетчера (shedul-ing latency) - время от момента окончания выполнения последней инструкции пользовательского обработчика прерываний до момента выполнения первой инструкции процесса, перешедшего в состояние ready из-за этого прерывания;
  
• время  переключения  контекста (context switch) - время от момента окончания выполнения последней инструкции одного процесса (потока) пользователя до момента начала выполнения первой инструкции следующего пользовательского процесса (потока);
  
• время реакции задачи (task response) - время от момента возникновения физического прерывания до начала выполнения первой инструкции задачи пользователя, которой предназначено прерывание;
  
• неустойчивость таймера (timer jitter) - разница во времени срабатывания таймера с фиксированной длительностью.
  

Кроме того, в литературе часто используются другие параметры для характеристики детерминизма и производительности ОСРВ, такие как:

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

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

Данные для LynxOS [5] в зависимости от функциональности и аппаратной платформы приведены в табл. 2. Интересные данные приводятся в исследовании Comparision between QNX RTOS 6.1, VxWorks AE 1.1 and Windows CE.NET (http://photon.qnx.com/download/download/8124/QNX_Neutrino_v61_vs_V XAE_and_WinCE.pdf), проведённом экспертами журнала Dedicated Systems (табл. 3).

Таблица 2. Результаты тестирования LynxOS

Ресурсы, требуемые для ОСРВ

Во многих обзорах по ОС, и в том числе ОСРВ, приводятся данные о ресурсах, требуемых для работы ОС. Чаще всего указывается минимальный размер ядра и оперативной памяти. Однако здесь надо чётко отделить рекламные характеристики и рабочие данные. Рекламные характеристики даются для абсолютно вырожденных конфигураций, которые нельзя использовать ни в одном реальном проекте и которые могут на порядок отличаться от рабочих конфигураций. Рабочие данные - это типовые случаи для реальных приложений, которые включают поддержку таких возможностей, как работа с файловой системой, терминалами, сетью. Учитывая это замечание, приведём данные для некоторых рабочих конфигураций ОСРВ, чтобы можно было оценить порядок требуемых ресурсов. Например, в качестве рекламной характеристики указывается значение 64K для конфигурации ОСРВ, состоящей из микроядра и менеджера процессов, хотя никакое реальное приложение с такой конфигурацией не имеет практического смысла. Размер работоспособного приложения с микроядром и минимальным числом сервисов приводит к требуемому объёму диска или флэш-памяти около 1М.

Данные для LynxOS [5] в зависимости от конфигурации ядра и аппаратной платформы приводятся в табл. 4.

Таблица 4. Пример требуемых ресурсов для LynxOS

Монолитное или микроядро?

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

Микроядро предоставляет только элементарные функции управления процессами и минимальный набор абстракций для работы с оборудованием. Основная часть работы осуществляется с помощью специальных пользовательских процессов, называемых сервисами. Достоинства: устойчивость к сбоям оборудования и ошибкам в компонентах системы. Недостатки: передача данных между процессами требует накладных расходов. Какой вариант ядра - монолитное или микроядро - является наиболее приемлемым для современных ОСРВ? Некоторые из ОСРВ имеют микроядро (QNX Neutrino, Integrity, VxWorks), некоторые - монолитное ядро (LynxOS). Спор по этому вопросу ведётся давно. Наиболее известной была дискуссия в 1992 г. между Эндрю Таненбаумом (Andrew Tanen-baum), разработчиком ОС Minix, и Линусом Торвальдсом (Linus Tor-valds), разработчиком Linux, в статье "Linux устарел" (http://www.bellevue-linux.org/obsolete.html). В этой дискуссии рассматривается множество аргументов "за" и "против" двух фундаментальных подходов к построению ОС (поддержка многозадачности, много-поточность в ядре, переносимость и другие), которые применимы и к ОСРВ. Но если придерживаться позиции, что практика - это основной критерий истины, то мы должны признать, что в настоящее время нет окончательного ответа на этот вопрос. Нет явного лидерства ни одной из этих двух архитектур по двум основным параметрам, по которым их чаще всего сравнивают: требуемым ресурсам и времени реакции.

Коммерческие или собственные ОСРВ

Для многих заказчиков по-прежнему не всегда ясен ответ на вопрос: надо ли для конкретного проекта разрабатывать собственную ОС или стоит воспользоваться коммерческой ОСРВ? Особенно это актуально для проектов в области обороны и авионики. По оценке Venture Development Corp. (VDC), одной из ведущих компаний в области ГГ-анализа, в 1998 г. до 50% проектов были разработаны с использованием собственных (in-house) инструментальных технологий.

Аналогичный анализ, проведённый VDC в 2004 г., показал следующие результаты: в 44% проектов использовались коммерческие ОСРВ, в 20% - ОС с открытым кодом и лишь для 19% проектов - собственные ОС. Компания VDC делает вывод об ускоренном переходе на коммерческие ОСРВ и задаётся вопросом: почему? Компании VDC и Evans Data Corporation (ещё одно известное консалтинговое агентство) выделяют следующие основные факторы, которые играют главную роль в этом процессе:

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

Классические требования к ОСРВ

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

• свойства ядра (архитектура, поддержка множества процессов и множества процессоров, устойчивость к отказам);
  
• диспетчеризация (алгоритм, механизм  присвоения  приоритетов, время для освобождения задачи);
  
• модель процесс/нить/задача (число уровней приоритетов, защита от инверсии приоритетов, состояния задачи, максимальное число задач, задержка переключения задач, динамическое изменение приоритетов);
  
• управление памятью (минимальный и максимальный объём оперативной и ROM-памяти на задачу, максимальная адресуемая память для задачи, поддержка защиты памяти, динамическое распределение памяти, виртуальная память, сжатие памяти);
  
• управление прерываниями и исключениями (вытесняемые обработчики прерываний, наихудшее время обработки прерывания, модифицируемость таблицы векторов прерываний);
  
• интерфейс прикладного программирования (совместимость библиотек, точное абсолютное время, поддержка внешних часов, примитивы синхронизации, сетевые протоколы, соответствие стандартам, ввод/вывод, файловые системы);
  
• процесс разработки (методология разработки, поставка в исходных или объектных кодах, поддерживаемые компиляторы, процессоры и языки программирования);
  
• коммерческая информация (стоимость, платежи за runtime-системы, срок присутствия на рынке, использование в ответственных приложениях, тип и стоимость технической поддержки).
  

Одним из немногих стандартов, формально определяющих некоторые классические требования к ОСРВ, является POSIX (Portable Operating System interface for unIX) - переносимый интерфейс ОС на уровне исходных текстов (http://www.pasc.org), первое описание которого было опубликовано в 1986 г. Основная спецификация разработана как IEEE 1003.1 и одобрена как международный стандарт ISO/IEC 9945-1:1990. С точки зрения ОСРВ, наибольший интерес представляют три стандарта: 1003.1а (OS Definition), 1003.1b (Realtime Extensions) и 1003.1c (Threads). Применительно к группе стандартов POSIX и ОСРВ, в английском языке часто используется не один, а целых три термина. К сожалению, они сходны по значению и часто переводятся одинаково, что вносит определенную путаницу.

Термины эти таковы:

• Compatibility (буквально "совместимость");
  
• Compliance (буквально "соответствие");
  
• Conformance (буквально "согласованность").
  

Первый термин применительно к POSIX формально не определён. Второй термин означает, что организация - производитель программного продукта самостоятельно заявляет о том, что продукт соответствует стандарту (полностью или частично) и протестирован с помощью тестов NIST-PCTS. Третий термин подразумевает, что программный продукт прошёл установленную систему тестов либо с помощью аккредитованной лаборатории, либо в рамках Open Group, и на это имеется документальное подтверждение (так называемое Conformance Statement). Если придерживаться строгих правил, требующих, чтобы данные о сертифицированной ОСРВ были опубликованы в официальном реестре IEEE и тестирование проводилось по уровню Conformance, то в настоящее время есть всего две сертифицированные ОСРВ: LynxOS (http://stan-dards.ieee.org/regauth/posix/posix2.ht ml) и Integrity (http://get.posixcertified.ieee.org/ select_product.tpl).

Влияние Linux-сообщества на развитие ОСРВ

ОСРВ испытывают постоянное влияние со стороны Linux-сообщества. Это находит отражение в виде нескольких тенденций:

1. Поставщики ОСРВ разрабатывают универсальные средства разработки, пригодные как для ОСРВ, так и для Linux (LynuxWorks, WindRiver, Green Hills, ATI);
   
2. Многие идеи, разрабатываемые в Linux-сообществе, реализуются в ОСРВ. Здесь в первую очередь следует назвать организацию OSDL (Open Source Development Labs, www.osdl.org), основанную в 2000 г. ведущими игроками рынка IT-ин-дустрии (IBM, HP, CA, Intel и NEC). В частности, разрабатываемая в рамках OSDL концепция Carrier Grade Linux находит отражение и в ОСРВ, например, в реализации таких возможностей, как QoP (Quality of Protection), LSB (Linux Standard Base), TIPC (Transparent Inter Process   Communication).   Протокол TIPC представляет собой новый стандарт для обеспечения взаимодействия между ОС в сетевых средах, телекоммуникационных кластерах и других многопроцессорных системах связи, а также систем с многоядерной или AdvancedTCA-архитектурой. Протокол TIPC уже реализован в некоторых ОСРВ, например, VxWorks и QNX Neutrino;
   
3. Linux рассматривается как одна из трёх основных хост-платформ для большинства ОСРВ (наряду с Windows и Solaris). В связи с этим поставщики ОСРВ особое внимание уделяют разработке удобных интегрированных сред на базе открытой платформы Eclipse (www.eclipse.org), которая заняла нишу, ранее занимаемую средой CodeWarrior IDE от Metrowerks. Собственные интегрированные среды (IDE) на базе Eclipse появились у многих поставщиков ОСРВ (LynuxWorks, QNX, WindRiver, Accelerated Technology).
   

Многоядерные процессоры и ОСРВ

Многоядерные процессоры требуют от производителей ОСРВ поддержки различных архитектур многопроцессорной обработки. Одним из лидеров здесь является компания QNX Software Systems, которая объявила о выпуске комплекта разработчика QNX Momentics Multi-Core Edition -набора инструментов разработки и миграции программного обеспечения (ПО) многоядерных аппаратных решений компаний Freescale и Intel.

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

• Стандарт ARINC-653 (Avionics Application Software Standard Interface). Об этом стандарте мы поговорим более подробно ниже. Стандарт ARINC-653 реализован для различных ОСРВ: LynxOS-178, VxWorks, Integrity, CsLeos;
  
• User Mode Linux (UML) - Linux в пользовательском режиме. UML -это самый универсальный эмулятор, позволяющий создавать виртуальные машины с оборудованием, которого может и не быть на физическом компьютере. Одним из лидеров в области внедрения UMLдля архитектур x86 и PowerPC является компания LynuxWorks;
  

Программные среды виртуальных машин, которые позволяют запускать на компьютере одновременно несколько разных ОС и переключаться из одной О С в другую без перезапуска компьютера. На сегодняшний день двумя самыми популярными программными средами виртуальных машин являются MS Virtual PC и группа продуктов VMware. Технология виртуализации Intel (VT) является компонентой многоядерной технологии, обеспечивающей поддержку виртуализации на аппаратном уровне.

Внедрение многоядерных процессоров повлечёт за собой повсеместное использование специализированных библиотек и систем параллельного программирования. Наметились три основных подхода к реализации этих систем, отличающихся методами взаимодействия параллельных задач. Один подход строится на основе концепции обмена сообщениями, второй - на использовании разделяемой памяти. Третий подход - на основе стандарта POSIX -объединяет оба этих подхода.

Наиболее известным представителем первой группы является спецификация MPI (Message Passing Interface) для языков программирования Cи и Фортран. Первый вариант спецификации MPI был разработан в 1994 г. Спецификация MPI включает около 200 функций и реализована для множества компиляторов и операционных систем. Одной из наиболее распространённых реализаций MPI является библиотека MPICH. Кроме того, на рынке представлены несколько коммерческих реализаций MPI, например, MPI/Pro производства компании Verari Systems Software для различных операционных систем, включая Windows, Linux, Mac OS X, LynxOS, а также таких коммуникационных сред, как Gigabit Ethernet, Myrinet и InfiniBand. MPI/Pro оптимизирует время работы параллельных приложений и обеспечивает их масштабируемость, осуществляя балансировку параметров производительности и использования ресурсов.

Представителем второй группы систем параллельного программирования является спецификация OpenMP (Open specifications for Multi-Processing), первая версия которой (www.openmp.org) появилась в 1997 г. и предназначалась для языка программирования Фортран. У истоков ОрепМР стояли компании IBM, Intel, Sun и Hewlett-Packard. В 1998 г. появились варианты OpenMP для языков Cи/C++, и сегодня последней является версия 2.5.

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

Отраслевые требования к ОСРВ

Почему к ОСРВ стали предъявляться новые, более серьёзные требования? Ответ на этот вопрос дают данные, приведённые в табл. 5.

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

• ОСРВ должны обеспечивать высокую степень "живучести" системы так, чтобы при отказе какой-либо части ПО другая часть ПО продолжала  нормально  функционировать. ОСРВ должна гарантировать отсутствие общего отказа системы;
  
• ОСРВ должны удовлетворять жёстким требованиям по качеству ПО, что подразумевает соответствие различным  отраслевым,  национальным и международным стандартам [6]. Особенностью требований к ОСРВ является то, что ПО должно иметь доказанное качество и во многих случаях должно быть сертифицировано уполномоченными организациями;
  
• требование по надёжности: вероятность сбоя в ПО должна быть очень маленькая;
  
• требования по безопасности (safety) и секретности (security) данных: в системе должны быть предусмотрены средства защиты наиболее важной информации.
  

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

1. Стандарт DO-178 (Software Consideration in Airborne Systems and Equipment Certification). Определяет процедуры сертификации ПО на основе требуемого уровня качества ПО. Разработан и поддерживается ассоциацией RTCA (Radio Technical Commission for Aeronautics, http://www.rtca.org). Первая версия стандарта принята в 1982 г., вторая (DO-178A) - в 1985. Текущая версия DO-178B принята в 1992 г. Новая версия DO-178C готовится специальным комитетом RTCA SC-205 WG-71 EUROCAE (European Organization for Civil Aviation Equipment). Первое заседание SC-205 проведено в марте 2005 г. По планам стандарт DO-178C будет готов в 2008 г. Стандартом определено пять уровней серьёзности отказа (A, B, C, D, E). Для каждого уровня определён набор требований к ПО, которые должны гарантировать работоспособность всей системы в целом при возникновении отказов данного уровня серьёзности;
   
2. ARINC 653 (Avionics Application Software Standard Interface) [7, 8, 9]. Стандарт разработан компанией ARINC (Aeronautical Radio, Inc.) в 1997 г. и вводит концепцию изолированных разделов на основе универсального программного интерфейса APEX (Application/Executive) между ОСРВ и прикладным ПО (http://www.arinc.com/cf/store/do-cumentlist.cfm). Требования интерфейса между прикладным ПО и сервисами ОС определяются таким образом, чтобы разрешить прикладному ПО контролировать диспетчеризацию, связь и состояние внутренних обрабатываемых элементов. В 2003 г. принята новая редакция. Стандарт ARINC 653 в качестве одного из основных требований для ОСРВ в авиации вводит архитектуру изолированных (partitioning) виртуальных машин;
   
3. Общие критерии для оценки безопасности   информационных технологий (Common Criteria for Information Technology Security Evaluation - CCITSE) [10, 11]. Это набор требований и условий безопасности, одобренный Агентством национальной безопасности и   Национальным   институтом стандартов и технологий США (http://csrc.nist.gov/cc/), а также соответствующими органами в других странах (в данный момент ещё 13 стран, кроме США). Первая версия требований опубликована в январе 1996 г., вторая - в апреле 1998 г. В 1999 г. CCITSE получил статус международного стандарта ISO 15408. Дополнительная информация по сертификации CCITSE находится на сайте: http://www.commoncrite-ria.org.
   
4. MILS (Multiple Independent Levels of Security/Safety). MILS делает возможной математическую верификацию программного ядра системы путём уменьшения функциональности за счёт предъявления к системам четырёх обязательных групп требований (Information Flow, Data Isolation, Period Processing, Damage Limitation).   Развивается   проект усилиями заинтересованных компаний и организаций, таких как U.S. Air Force Research Laboratory, Lockheed Martin, Агентство национальной безопасности США и др. (http://mils.ois.com).
   
5. 5 Reusable Software Components (повторно используемые компоненты ПО), разработка Federal Aviation Administration, документ AC 20-148, декабрь 2004 г. Определяет критерии возможности многократного использования ПО без повторной сертификации.
   

Среди   российских   документов, определяющих требования к ПО (в т.ч. к ОСРВ), назовём следующие:

1. ГОСТ Р ИСО/МЭК 51904-2002 ("Программное обеспечение встроенных систем. Общие требования к разработке и документированию");
   
2. ГОСТ Р ИСО/МЭК 12207-99 ("Информационная технология. Процессы  жизненного  цикла   программных средств");
   
3. ГОСТ Р ИСО/МЭК 15408-2002 ("Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий").
   

Таблица 5. Характеристики программного обеспечения в различных отраслях*

*Источник: Real-time and Embedded Systems Forum, 2001, http://www.opengroup.org/rtforum/jul2001/minutes.html.

LynxOS, LynxOS-178 и LynxSecure

ОС LynxOS - ОСЖРВ от компании LynuxWorks, поддерживающая многозадачные и многопоточные приложения. Она может использоваться для приложений с высокими требованиями по времени реакции и надёжности. Система сертифицирована на соответствие стандарту POSIX 1003.1-1996 для архитектуры Intel и PowerPC. Полностью поддерживается стандарт POSIX.1003.1a, а также подразделы POSIX.1003.1b и POSIX.1003.1c. ОС LynxOS обеспечивает совместимость с Linux на уровне двоичного кода (программы, написанные и компилированные в ОС Linux, могут запускаться и работать в среде LynxOS без каких-либо изменений в исходных текстах и без перекомпилирования). ОС LynxOS является многоплатформенной ОСРВ: поддерживает аппаратные архитектуры LA-32, PowerPC, MIPS, ARM, XScale и является ОС для ответственных приложений за счёт наличия средств для создания современных систем, обладающих свойствами "горячей" замены/высокой доступности (Hot Swap, High Availability), и устройств с высоким коэффициентом резервирования.

ОС LynxOS-178 выпущена в начале 2003 г. и является ОСРВ в стандарте POSIX. Система сертифицирована в составе изделий по стандарту DO-178B уровня A. Она соответствует стандарту ARINC 653 и в марте 2006 г. получила сертификат RSC (Reusable Software Components) от FAA. ОС LynxOS-178, версия 2.0, допускает до 16 разделов (виртуальных машин), включая корневой раздел, до 64 процессов в каждом разделе, до 51 потока (нити) внутри каждого процесса. Обеспечивается диспетчеризация реального времени потоков внутри раздела и POSIX-функции межпроцессного взаимодействия внутри раздела. ОС LynxOS-178 сертифицирована в июне 2003 г. по DO-178B уровня А в составе изделия КС-135 Stratotanker, используемого для дозаправки в воздухе стратегических бомбардировщиков дальнего действия.

Ядро LynxSecure - фундамент систем безопасности встраиваемого ПО ближайшего будущего. Ядро будет сертифицировано по DO-178B уровня А и на соответствие уровню EAL-7 (Evaluated Assurance Level 7) в рамках "Общих критериев для оценки безопасности информационных технологий" (Common Criteria). Ядро LynxSecure cоставит основу приложений с архитектурой MILS (Multiple Independent Levels of Security). В среде LynxSecure ОС BlueCat Linux и ОС LynxOS-178 смогут работать в пользовательском режиме как изолированные друг от друга процессы. Объём исходного кода LynxSecure составит всего 8 тыс. строк.

Все три ОСРВ от компании LynuxWorks поддерживаются общим набором средств разработки: на основе GNU (gcc, gdb и другие) на кросс-платформе Linux, Windows и native (LynxOS) ОС. Компания LynuxWorks поставляет интегрированные среды разработки (IDE) VisualLynux на Windows-хосте, CodeWarrior и Luminosity (вариант Eclipse) на Linux-хосте, SpyKer - средство тестирования в реальном времени, LynxInsure++ -средство верификации программ.

VxWorks и VxWorks АЕ-653

ОСРВ VxWorks и инструментальная среда Tornado являются визитной карточкой фирмы Wind River Systems. ОС VxWorks - это наиболее типичный и известный представитель кросс-платформных ОСРВ со своим собственным API, несовместимым с каким-либо стандартом. В то же время в этом API реализованы многие базовые функции ОСРВ, такие как планирование задач на основе вытеснения по приоритетам и круговое планирование, средства межзадачных коммуникаций: семафоры, сигналы, очереди сообщений, каналы, сокеты, удалённый вызов процедур и разделяемая память. ОС VxWorks, на протяжении многих лет безусловный лидер на рынке ОСРВ, постепенно утрачивает свои позиции в относительном выражении (по оценкам журнала EETimes, http://www.ee-times.com/story/OEG200402 20S0041), что, на наш взгляд, в первую очередь объясняется именно несоответствием стандартам. Другими причинами являются ограниченность лежащей в основе VxWorks (до версии 5.4) одно-процессной модели и отсутствие защиты памяти для задач ("плоская" модель памяти). Хотя сейчас некоторые из ограничений частично устранены (полнота соответствия POSIX, поддержка MMU), указанный тренд сокращения доли рынка за VxWorks сохраняется.

VxWorks AE-653 - это расширение VxWorks, которое соответствует концепции ARINC-653 и может быть сертифицировано по DO-178B. Для этого в VxWorks AE-653 введён механизм защищенных доменов, добавлен диспетчер разделов, автоматическое восстановление ресурсов, именованные объекты. Расширение VxWorks AE-653 сертифицировано по DO- 178B в составе изделия КС-767А в октябре 2003 г.

Компания Wind River известна как поставщик широкого набора инструментальных средств различного назначения. В 1995 г. была выпущена интегрированная среда Tornado 1.0 -первая среда разработки ПО встраиваемых систем с открытой архитектурой. Среди других средств от Wind-River назовём VxSim - симулятор VxWorks, WindView и StethoScope -средства отладки в реальном масштабе времени, WindNavigator - средство управления большим программным проектом, CodeTest - верификатор встроенного программного обеспечения, Visual SlickEdit - редактор исходных текстов, Look! - динамический визуализатор объектных приложений и другие.

QNX Neutrino

QNX является наиболее известной в отечественной печати ОСРВ. C 1980 г. выпущено три поколения этой ОСРВ: QNX2, QNX4, QNX Neutrino (QNX6). Сейчас активно развивается версия QNX Neutrino 6.3 - многоплатформенная ОСРВ, в основе которой лежит POSIX и архитектура микроядра. Компания QNX Software Systems (SS) начала в мае 2003 г. работы по формальной сертификации QNX Neutrino по POSIX-2003.

QNX Neutrino поддерживает основные многопроцессорные (и аналогичные) архитектуры, такие как Asymmetric & Symmetric Multiprocessing (AMP & SMP), протокол TIPC (Transparent Inter-Processor Communication), BSP для многоядерных платформ на базе MIPS, PowerPC и x86.

В настоящее время в QNX Neutrino нет поддержки ARINC-653. Но ожидается, что QNX SS реализует поддержку функционально похожей технологии, которая будет называться adaptive partitioning.

Integrity и Integrity-178

Было не понятно, почему в печати так мало технической информации по ОСРВ Integrity, пока не появилась информация о том, что Integrity создавалась для систем управления ядерным оружием. Об архитектуре Integrity известно следующее: в основе ОСРВ лежит микроядро velOSity. ОС Integrity сертифицирована по POSIX 1003.1-2003 (System Interfaces) в июле 2004 г. (http://get.posixcertified.ieee.org/select_product.tpl) для архитектуры PowerPC. ОСРВ Integrity является многоплатформенной кросс-системой, поддерживающей различные процессорные архитектуры (PowerPC, ARM, MIPS, Intel XScale, Analog Devices Blackfin, TI OMAP).

Integrity очень хорошо интегрирована с различными средствами разработки от компании Green Hills, особенно с интегрированной средой MULTI, оптимизированной для языков программирования Ada 95, Cи и C++. Кроме того, Integrity включает компонент EventAnalyzer , который позволяет отображать системные и пользовательские события в графическом виде.

Ядро Integrity-178B - это подмножество ОСРВ Integrity, включающее поддержку интерфейса ARINC 653. ОСРВ Integrity-178B вместе с GSTART сертифицирована по уровню А стандарта DO-178B в составе вертолёта Sikorsky S-92 компании Rockwell Collins в ноябре 2002 г.

Nucleus Plus

ОС Nucleus основана на многозадачном ядре реального времени Nucleus Plus. Она имеет свой собственный API, не соответствующий какому-либо стандарту, является кросс-системой и поставляется в исходных текстах. Стоимость Nucleus с дополнительными пакетами находится в диапазоне от 15 до 50 тыс. долл. Nucleus Plus включает в себя достаточно полный набор средств разработки встраиваемых приложений, работающих в реальном времени: стандартные средства управления задачами межзадачного обмена (почтовые ящики, очереди, конвейеры, семафоры, события, сигналы), управления памятью, таймерами и прерываниями. В нём реализованы два алгоритма диспетчеризации: по приоритетам задач и FIFO. ОС Nucleus может работать более чем с 70 различными комбинациями компиляторов и процессоров. Компания Accelerated Technology поддерживает процессоры для RISC-, CISC- и DSP-архитектур. Дляпереноса Nucleus на любую другую платформу достаточно модифицировать три аппаратно-зависимых компонента: модули инициализации Initialization (INT), планирования Sheduling (TMT) и управления таймерами Clock Management (TCT).

Nucleus Plus может дополняться такими пакетами, как Nucleus Net, Nucleus SNMP, Nucleus RMON, Nucleus Span (реализует спецификацию Spanning Tree), Nucleus File, Nucleus WebServ, Nucleus JV (Java Virtual Machine), Nucleus Grafix. Особо отметим две дополнительные компоненты: Nucleus POSIX и Nucleus DO-178B.

Nucleus POSIX - это дополнительная компонента к ядру Nucleus Plus, выпущенная на рынок в феврале 2005 г. Цена этой компоненты составляет (в США) не менее 2995 долл.

Nucleus DO-178B - Nucleus Plus, сертифицированная компанией Accelerated Technology совместно с фирмой Cascade Engineering Services по стандарту DO-178B уровня А.

CsLeos

CsLeos - это первая коммерческая ОСРВ, в которой ARINC-653 был базовым интерфейсом, а не расширением операционной системы. Время рождения этой ОСРВ - июль 2002 г. Это определило механизм реализации многих прикладных свойств на основе концепции виртуальных машин. В частности, поддержка графического интерфейса OpenGL была реализована в виде самостоятельной виртуальной машины. Аналогичным способом были реализованы средства тестирования самой операционной системы, которые значительно облегчили её сертификацию в соответствии с DO-178B уровня А. Основной процессорной архитектурой для CsLeos является PowerPC.

Как сообщает фирма ВАЕ (разработчик CsLeos), стоимость набора средств разработки CsLeos составляет (в США) не менее в 50 000 долл. и включает следующий набор средств:

• CsLEOS,
  
• RTOS Tools,
  
• CsLEOS RTOS Configuration Tool,
  
• CsGTI (Graphical Test Interface) software test tool,
  
• DDC-I SCORE-653 development environment,
  
• Rational Software Test RealTime test coverage tools,
  
• A3 ARINC-653 Development Tool.
  

Дополнительно заказчику может быть поставлен пакет для сертификации по стандарту DO-178В. ОСРВ CsLeos сертифицирована по стандарту DO-178В уровня А.

Какие изменения ожидают рынок осрв в ближайшем будущем?

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

1. Развитие средств поддержки многоядерных процессорных архитектур (табл. 6), которые в ближайшее время будут определять основной тренд развития процессоров для всех сегментов рынка (серверы, настольные системы, мобильные и встраиваемые системы) [12]. По сути дела многоядерная архитектура открывает новый путь для реализации задач реального времени, но уже на аппаратно-программном уровне;
   
2. Продолжение тенденции перехода заказчиков от собственных (in-house) к коммерческим ОСРВ;
   
3. Расширение возможностей Linux с точки зрения поддержки жёсткого реального времени [13];
   
4. Появятся первые ОСРВ, сертифицированные по уровню EAL-7 в рамках  "Общих  критериев  для оценки безопасности информационных технологий".
   

Как в действительности будут развиваться события - покажет время.

Таблица 6. Прогноз развития рынка средств поддержки многоядерных процессорных архитектур*

^*Источник: Intel Corporation

Литература

1. Жданов А.А. Операционные системы реального времени. PCWeek. 1999. 8.
   
2. Сигаев А. Операционные системы для встраиваемых применений. Компоненты и технологии. 2000. 4.
   
3. Melanson Ph., Tafazoli S. A Selection Methodology for the RTOS Market, Canadian Space Agency, Space Technologies Branch, Software and Ground Segment 6767 route de l'Aeropor. St-Hubert, Quebec, Canada. J3Y 8Y9.
   
4. Kevin M. Obeland, POSIX in Real-Time, Embedded Systems Programming. 2001.
   
5. The  LynxOS  3.0.1   Performance  Page (http://www.ro.feri.uni-mb.si/predst/mar-tin/4_ 12_2000/301specs.html).
   
6. Commercial Off-The-Self Real-Time Operating System and Architectural Consideration. Final Report. U.S. Federal Aviation Administration, DOT/FAA/AR/03/77. February 2004.
   
7. Partitioning in Avionics. Architecture: Requirements, Mechanics and Assurance. Final Report. National Aeronautics and Space Administration. DOT/FAA/AR/99/58, NASA/CR/1999/209347. March 2000.
   
8. Study   of   Commercial Off-The-Self (COTS)  Real-Time  Operating  System (RTOS) in Aviation Application. Final Report. U.S. Federal Aviation Administration. DOT/FAA/AR/02/118. December 2002.
   
9. Evaluation of real-time operating systems -the role of standards. Avionic Systems Standartisation Committee (ASSC). No: ASSC/330/2/141. March 1997.
   
10. COTS Security Protection Profile - Operating Systems (CSPP-OS). NISTIR 6985. April 2003.
    
11. Common  Criteria for Information Technology Security Evaluation. Part 3: Security Assurance Requirements. August 1999.   Version 2.1. CCIMB/99/033 (http://csrc.nist.gov/cc/Documents/CC%20v2.1/p3-v21.pdf).
    
12. Раманатан Р.М. Передовые технологии Intel - от настольных систем к телекоммуникациям (http://www.intel.com/cd/corporate/europe/emea/rus/update/251102?htm).
    
13. Embedded Linux on the Move. Dec 30, 2005  (http://www.realworldlinux-biz.com/artman/publish/embeds.shtml).
    

Об авторе: Сергей Золотарев сотрудник отдела программных продуктов компании RTSoft
Статья была опубликована на сайте rtsoft.ru
Помещена в музей с разрешения редакции 8 июля 2018