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

Реального времени (RTOS) - это ОС, которая гарантирует определенную способность в течение заданного временного отрезка. Например, она может быть спроектирована так, чтобы отображать, что некий объект стал доступен для робота на сборочном конвейере. Такие оболочки классифицируются на «жесткие» и «мягкие».

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

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

Прежде чем приводить примеры операционных систем реального времени, необходимо разобраться в особенностях их использования. Одни такие ОС создаются для специального применения, другие - для более общего. Кроме того, некоторые оболочки общего назначения также иногда используются для работы в режиме в реального времени. Как такого типа могут выступить общеизвестные Windows 2000 или IBM Microsoft/390. То есть даже если ОС не отвечает некоторым требованиям, она может иметь характеристики, которые позволяют рассматривать ее в качестве решения для конкретной задачи приложения в режиме реального времени.

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

В целом реального времени имеют следующие характерные черты:

• Многозадачность.
• Технологические потоки, которые могут быть приоритетными.
• Достаточное количество уровней прерываний.

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

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

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

VxWorks от компании WindRiver

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

VxWorks поддерживает Intel (x86, включая новый вариант IntelQuarkSoC и x86-64), MIPS, PowerPC, SH-4 и ARM-архитектуру. Данная ОСРВ поставляется с мощным ядром, промежуточным программным обеспечением, поддержкой платных дополнительных пакетов и аппаратных технологий сторонних производителей. В своем последнем выпуске - VxWorks 7 - система была модернизирована для модульности и апгрейда так, что ядро ​​ОС содержится отдельно от промежуточного программного обеспечения, приложений и других пакетов.

QNX Neutrino

Также классические примеры операционных систем указанного типа - некоторые Unix-подобные оболочки. Таковой является QNX Neutrino, первоначально разработанная в начале 1980-х годов канадской компанией Quantum Software Systems. В конечном счете, разработка была приобретена BlackBerry в 2010 году. QNX является одним из первых коммерчески успешных операционных систем микроядра, которая используется в различных устройствах, включая авто- и мобильные телефоны.

FreeRTOS

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

Windows CE

Windows Embedded Compact - это операционная система подсемейства, разработанная корпорацией «Майкрософт» в рамках семейства продуктов Windows Embedded. В отличие от Windows Embedded Standard, который основан на Windows NT, эти примеры операционных систем используют эксклюзивное гибридное ядро. Компания «Майкрософт» предоставляет лицензии Windows CE для производителей оригинального оборудования, которые могут изменять и создавать свои собственные пользовательские интерфейсы, обеспечивая техническую основу для этого.

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

05.05.2008, ПН, 23:56, Мск

Благодаря развитию вычислительной техники в последнее время стало возможным возложить на один модуль задачи, выполняемые ранее несколькими процессорными модулями, при этом улучшив массогабаритные характеристики системы управления и снизив ее стоимость. Такая тенденция в авиационной технике привела к появлению концепции интегрированной модульной авионики - ИМА (Integrated Modular Avionics,IMA).

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

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

Документы, регламентирующие требования к ОСРВ

Стандарт DO-178 (Software Consideration in Airborne Systems and Equipment Certification) определяет требования к процессу разработки программного обеспечения и тщательности его проверки в зависимости от его уровня критичности. Уровень критичности ПО определяется на основе анализа серьезности последствий отказа в ПО. Всего предусмотрено пять уровней критичности ПО (от A до E).

MILS (Multiple Independent Levels of Secutiry) представляет собой специальный подход к проектированию ОС, препятствующий распространению ошибок прикладного программного обеспечения во время выполнения, а также упрощающий верификацию программ за счет модульности ПО. Все приложения помещаются в так называемые разделы (partitions). Разделы имеют выделенные ресурсы (область памяти, процессорное время в течение каждого цикла системы, доступ к каналам обмена и пр). Доступ к выделенным ресурсам гарантируется ОС, работающей в режиме супервизора. Таким образом, на одном процессорном модуле под управлением одной ОС может работать прикладное ПО разного уровня критичности - если сбой произойдет в менее критичном (и, соответственно, менее проверенном) ПО, это никак не повлияет на работу других разделов, так как попытки «узурпировать» чужие ресурсы будут пресечены операционной системой. Идеи MILS перекликаются с идеями ИМА и DO-178B.

Ошибка 404. Не удаётся найти страницу.

Возможно, это случилось по одной из этих причин:

– ошибка при наборе адреса страницы (URL)
– переход по «битой» (неработающей, неправильной) ссылке
– запрашиваемой страницы никогда не было на сайте или она была удалена

Вы можете:

– вернуться назад при помощи кнопки браузера Назад (Back)
– проверить правильность написания адреса страницы (URL)
– воспользоваться картой сайта или перейти на главную страницу

Стандарт ARINC-653 (Avionics Application Software Standard Interface) специфицирует интерфейс прикладного программного обеспечения APEX, поддерживающий концепцию разделов в духе MILS. Данный интерфейс включает функции управления разделами, процессами, разделением времени, коммуникациями между разделами и внутри раздела, мониторинг состояния системы. Надо отметить, что стандарт ARINC-653 описывает общепризнанный подход к реализации идей MILS для ИМА, хотя могут быть и другие реализации. Авиационная ОСРВ, соответствующая ARINC-653, имеет преимущества, так как данный стандарт хорошо известен и понятен международным сертифицирующим органам, поэтому на систему, построенную по этому стандарту, проще получить сертификат соответствия DO-178B.

Стандарт Reusable Software Components. В соответствии с DO-178B программное обеспечение той или иной системы авиационного применения проходит процедуру сертификации полностью, даже если оно использует модули (компоненты), которые уже были сертифицированы ранее в составе другой системы. Одной из последних инициатив FAA (Федеральное агентство по сертификации гражданской авиации, США) является определение критериев возможности многократного использования ПО без повторной сертификации. Компоненты, которые можно повторно не сертифицировать, называются RSC (Reusable Software Components). Чтобы получить сертификат на RSC, нужно затратить больше усилий, но затем RSC дает серьезную экономию.

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

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

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

Временные параметры ОС

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

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

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

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

Достаточно объективными данными можно считать результаты, полученные экспертами журнала Dedicated System, проводившими тестирование и практическое сравнение QNX RTOS 6.1, VxWorks AE 1.1 и Windows CE.NET на x86 платформе. Хотя на сегодняшний момент эти данные устарели, авторам данной статьи не удалось найти более свежего материала. В табл. 2 приведены выборочные данные о сравнении производительности QNX Neutrino 6.1, VxWorks AE 1.1. В отчете Dedicated Systems предпочтение с точки зрения быстродействия было отдано QNX, причем отношение баллов было установлено как 9:5 (QNX:VxWorks), потому как в процессе тестирования в VxWorks были обнаружены две ошибки, за исправлением которых пришлось обращаться в службу поддержки.

В табл. 3 приведены данные о характеристиках LynxOS. Состав использовавшихся тестов не указан. В качестве данных о характеристиках LynxOS интересна четвертая колонка (тестирование на x86-платформе). По сравнению с VxWorks и QNX, ОС РВ LynxOS показывает огромную задержку при реакции на прерывание (более чем в 5 раз). Время переключение контекста (имеется в виду время переключения между двумя потоками в одном процессе) одинаковое с QNX и меньше примерно в 1,5 раза, чем у VxWorks.

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

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

Исходя из данных журнала Dedicated System, QNX опережает по этому критерию VxWorks как по разбросу характеристик в серии однотипных тестов (отношение максимума времени к среднему значению существенно меньше), так и с ростом нагрузки (время переключения потока при увеличении числа потоков 2...128 ед. у QNX выросло только в 1,65 раза, тогда как у VxWorks - в 2,24 раза).

По данным, полученным в компании РТСофт, известно, что LynxOS имеет приблизительно те же характеристики, что VxWorks.

Управление доступом к ресурсам

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

Первый вопрос, на который нужно найти ответ - поддерживает ли ОС модель процессов. Процесс - это логический объект, который владеет одним или несколькими потоками, ассоциированными с ними ресурсами и контекстом - содержимым регистров и счетчиков в каждый отдельный момент времени.

Задача процессов состоит:

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

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

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

Поддержка мультипроцессорных и распределенных систем

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

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

ОС РВ QNX предлагает поддержку многопроцессорных плат. Для VxWorks такая поддержка пока только анонсирована. Авиационной версии LynxOS с поддержкой многопроцессорных плат пока тоже не существует.

В отношении поддержки сетевых протоколов нужно отметить, что ОС РВ LynxOS, VxWorks и QNX обладают примерно равными (и широкими) возможностями. Дополнительным плюсом ОС РВ QNX является ее специальная архитектура сетевой подсистемы, обеспечивающая сетевую «прозрачность» прикладных программ: любой процесс может вызвать другой процесс на удаленном модуле так же, как и процесс на локальном модуле.

Поддержка файловых систем

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

В табл. 4 показана поддержка файловых систем каждой из рассматриваемых ОС.

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

Качество документации

Качество документации ОС РВ LynxOS, VxWorks, QNX достаточно высокое. Однако есть и нарекания по поводу документации:

• QNX - отличное описание архитектуры и принципов построения, но недостаточное описание интерфейса прикладного программирования (дано описание не всем параметрам, есть несоответствия);
• VxWorks - нет объяснения принципов работы и недостаточное описание сложного процесса конфигурирования ОС.

Тем не менее, компании работают над качеством материала. Документация на текущую версию QNX (6.3.2) существенно расширена, налицо переработка некоторых частей.

Качество технической поддержки

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

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

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

Открытость исходных кодов

Открытая ОС РВ имеет по крайней мере три преимущества:

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

С сентября 2007 года компания QSS открыла исходные коды ядра QNX (включая пакет сегментирования Adaptive Partitioning, пакет высокой готовности High Availability). Немногим позже были открыты исходные коды сетевой подсистемы. В настоящее время на официальном сайте доступна для скачивания бета-версия 6.4.0.

Надо отметить, что на сегодняшний день не все модули QNX открыты (например, нет кодов для графической и файловой систем), и лицензия налагает ограничение на использование «исходников»: только для некоммерческого применения. Тем не менее, пользователь QNX получает указанные выше преимущества бесплатно.

Исходные коды LynxOS и VxWorks доступны в продаже. Цена на такой продукт договорная.

Инструментальные средства

Наличие хороших инструментальных средств во многом определяет качество и скорость разработки прикладных программ под ту или иную ОС. Надо отметить, что LynxOS, VxWorks и QNX в настоящее время предоставляют хорошего качества инструментальные средства, которые включают интегрированную среду разработки (ИСР) и отладки прикладного ПО, средства профилирования программ (для обнаружения «узких мест» по производительности, памяти и пр.). Эргономика ИСР для данных ОС РВ в целом не уступает развитым средствам разработки для обычных ОС (например, MS Windows).

Переносимость прикладного ПО

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

Возможность написания переносимого ПО определяется в текущий момент соответствием стандарту POSIX. Все рассматриваемые ОС РВ поддерживают стандарт POSIX 1003.1. Преимущество есть у LynxOS - данная ОС обладает бинарной совместимостью с ОС Linux. То есть приложения Linux могут быть запущены под LynxOS без перекомпилирования. И, наоборот, приложения LynxOS могут быть запущены в Linux (версии 2.4.x c библиотекой языка Си glibs версии 2.2.2).

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

Поддержка процессорных архитектур

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

Соответствие авиационным стандартам

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

LynxOS в части соответствия стандартам является лидером. Она поддерживает ARINC-653, существует достаточно примеров систем, сертифицированных по DO-178B, построенных на ее основе. Ключевым моментом является то, что компания LynuxWorks предлагает набор RSC (правда, авторам статьи ничего не известно о цене).

VxWorks соответствует стандарту ARINC-653, и системы, построенные на ее основе, могут быть сертифицированы по DO-178B (существует большое число примеров).

QNX не соответствует ARINC-653, и пока не существует систем на их основе, сертифицированных по DO-178B.

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

В части аналогичных российских стандартов для военной авиации (ГОСТ Р ИСО/МЭК 51904-2002) нет еще ни одного примера сертифицированной системы, хотя принципиально на основе любой из рассматриваемых ОС можно такую систему разработать. Для ОС РВ QNX в настоящее время ведется работа по подготовке основных модулей ОС к сертификации.

Развитость системы подготовки специалистов

Быстрота и качество обучения персонала, работающего с ОС РВ и различными инструментариями по разработке и отладке ПО напрямую связано со скоростью разработки ПО и его качеством. Ведущие компании в области встроенного и системного ПО, такие как WindRiver, LynuxWorks, QSS, проводят широкомасштабную программу курсов и тренингов по изучению использования продуктов компании, в том числе и ОС РВ.

Результаты сравнения

ОСРВ QNX Neutrino является наиболее совершенной ОС с технической точки зрения, располагает хорошим набором инструментальных средств, имеет относительно невысокую цену. Микроядерная архитектура обеспечивает высокую надежность и модульность разрабатываемых систем. Дополнительным плюсом является открытость исходных кодов. Но есть и «ложка дегтя»: в настоящее время QNX практически нигде не используется в авиации, и по этому параметру данная ОС проигрывает конкурентам (LynxOS и VxWorks). Дополнительный минус QNX: несоответствие стандарту ARINC-653.

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

Работа по подготовке к сертификации QNX Neutrino по требованиям отечественных авиационных стандартов в настоящее время ведется компанией SWD Software.

ОСРВ LynxOS-178, напротив, имеет все необходимые сертификаты за рубежом, хотя по многим другим критериям выглядит менее предпочтительно, чем QNX Neutrino. Отметим, что для применения в российской авиационной промышленности ОСРВ LynxOS-178 также должна быть сертифицирована по отечественным ГОСТ.

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

Экспертная группа / R&D.CNews

Распечатать

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

Федеральная администрация по авиации США - одна из авторитетных организаций, отвечающих за безопасность полетов - предъявляет жесткие требования к коммерческим операционным системам реального времени, принятым для эксплуатации (особенно это касается гражданской авиации, где от их работы зависят жизни сотен пассажиров). Среди них:

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

Система регламентации требований

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

Стандарт DO-178 - Software Consideration in Airborne Systems and Equipment Certification. Разработан и поддерживается ассоциацией Radio Technical Commission for Aeronautics (RTCA, www.rtca.org ). Стандартом определено пять уровней серьезности отказа, для каждого из которых указывается набор требований к программному обеспечению, призванных гарантировать работоспособность всей системы в целом при возникновении отказов данного уровня:

уровень A - защита от сбоев, приводящих к катастрофическим последствиям;

уровень B - защита от сбоев, приводящих к опасным последствиям;

уровень C - защита от сбоев, приводящих к большим последствиям;

уровень D - защита от сбоев, приводящих к минимальным последствиям;

уровень E - защита от сбоев, не приводящих ни к каким последствиям.

Стандарт ED-12B. Европейский аналог DO-178B. Определяется ассоциацией The European organization for civil aviation equipment (EUROCAE, www.eurocae.org).

RTCA DO-248B - Final Annual Report For Clarification Of DO-178B. Пояснительный документ к 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, Агентство национальной безопасности США и др. Проект MILS делает возможной математическую верификацию программного ядра системы путем уменьшения функциональности за счет предъявления к системам четырех обязательных групп требований (Information Flow, Data Isolation, Period Processing, Damage Limitation). MILS-архитектура представляет собой систему с изолированными разделами, каждый из которых включает ядро, программное обеспечение промежуточного слоя и приложение (рис. 1).

Рис. 1. MILS-архитектура

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

Концепция изолированных разделов

По многим аспектам регламентирующие документы пересекаются, дополняя друг друга. В результате многочисленных исследований в качестве основной была принята концепция изолированных разделов . Удовлетворение требованиям жесткой изоляции должно быть «доказано» поставщиками программных решений в соответствии с методологией сертификации, изложенной в DO-178B. Существуют различные подходы к реализации изолированных разделов, однако сегодня принята архитектура, соответствующая ARINC 653, которая определяет поддержку изолирования для операционной системы реального времени и в качестве языка описания использует Cи и Ada-95.

С точки зрения пользователя, ARINC 653 представляет собой спецификацию интерфейса APEX (APplication/EXecutive) и не определяет его реализацию. Так, некоторые поставщики программных средств реализуют диспетчеризацию с помощью одноуровневого диспетчера, другие с помощью двухуровневого, когда первый уровень управляет разделами, а второй - процессами внутри каждого раздела. Такая ситуация с поддержкой ARINC 653 влечет за собой трудности при сертификации программных продуктов, соответствующих только ARINC 653 - один и тот же API может отображаться на различные подходы к реализации. Как следствие, появилось множество сильно отличающихся операционных систем реального времени, которые, однако, соответствуют спецификации ARINC 653.

На рис. 2 показана архитектура системы с несколькими изолированными разделами, каждый из которых представляет собой самостоятельное приложение. Все данные и программный код в каждом разделе собираются вместе и выполняются в пользовательском режиме. Компоненты «модульная операционная система» (Module Operating System, MOS) и «пакет поддержки платы» (Board Support Package, BSP) выполняются в режиме супервизора. Дополнительно может существовать один специальный раздел с некоторыми специальными возможностями, такими, как средства ввода-вывода и переключения режимов.

ARINC 653 как раз и задает интерфейс для обмена информацией между разделами, каждый из которых представляет собой некоторое приложение плюс операционную систему раздела (Partition Operating System, POS). Этот интерфейс должен гарантировать изоляцию перечисленных ниже элементов.

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

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

Программный код. Для некоторых областей памяти MOS устанавливает в режиме супервизора) атрибут «только выполнение». Это означает, что приложения в пользовательском режиме не могут разрушить область кода.

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

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

Другим источником прерываний являются внешние устройства ввода/вывода. В соответствии с требованиями ARINC 653, для устройств с синхронной передачей данных рекомендуется использовать алгоритм опроса устройства. Однако некоторые устройства требуют обработки прерываний. Эти прерывания должны обрабатываться MOS и затем передаваться в POS в момент активизации раздела. Очевидно, что при этом могут возникать временные задержки и даже потеря информации, и, следовательно, разработчик должен это учитывать.

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

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

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

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

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

Планирование согласно DO-178B должно включать следующие планы: план для программных аспектов сертификации; план программного проекта; план верификации программного обеспечения; план управления конфигурацией программного обеспечения; план гарантии качества программного обеспечения. На протяжении всего жизненного цикла должно быть обеспечено соответствие стандарту DO-178 в области формулировки требований, проектирования, кодирования, верификации и документирования. Должны быть разработаны требования к программному обеспечению (требования высокого уровня), проект программного обеспечения (требования и архитектура), программный код в исходном и объектном виде. Каждый из разработанных компонентов должен быть верифицирован по разнообразным критериям. Верификация требований высокого уровня к программному обеспечению включает в себя проверку следующих условий: требования соответствуют системным требованиям и доступны для анализа вместе с системными требованиями; требования являются точными и согласованными; требования совместимы с аппаратными средствами и, следовательно, должны быть подтверждены результатами.

Верификация проекта программного обеспечения включает в себя проверку того, что требования к проекту соответствуют требованиям высокого уровня и могут быть подвергнуты анализу, являются точными и согласованными и, следовательно, должны быть подтверждены результатами. Аналогично должны быть верифицированы архитектура и код программного обеспечения, которые, кроме того, должны соответствовать требованиям, закрепленным в DO-178B. Данный стандарт определяет процесс верификации этапа интеграции программного обеспечения, проверку полноты самого процесса верификации, обеспечение менеджмента конфигураций (в том числе управление версиями), квалификацию автоматизированных средств.

В стандарте определены три уровня структурного тестирования кода:

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

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

Сертификация на соответствие DO-178B должна проводиться так называемыми «назначаемыми инженерными представителями», которые назначаются Федеральной администрацией по авиации США для проверки данных, используемых при сертификации. Разработчик стремится пройти сертификацию своего программного обеспечения в соответствии с DO-178B для того, чтобы получить разрешение на использование своего программного обеспечения (в том числе операционной системы реального времени) в авиации. Разрешение относится не только к программному обеспечению, но и ко всему изделию (проекту) в целом. Для того чтобы начать процесс сертификации, разработчик должен вначале «открыть» проект и получить от ФАА официальный номер проекта или присоединиться к уже существующему проекту с уже выданным номером. Для «открытия» проекта надо получить сертификат типа или дополнительный сертификат типа. Как правило, сертификат типа присваивается самолету, и все оборудование на нем поставляется именно с этим сертификатом. Дополнительный сертификат типа дается дополнительному оборудованию на самолете, в том числе программному обеспечению.

«Общие критерии» для оценки секретности

«Общие критерии» определяют уровни гарантии секретности Evaluation Assurance Level (EAL) и оценивают не только безопасность и надежность продуктов, но и процессы их разработки и поддержки, гарантирующие быстрое решение проблем. Применительно к операционным системам требования «Общих критериев» подробно изложены в . Выделены семь уровней гарантии секретности :

EAL1 (functionally tested) - применим там, где требуется минимальная конфиденциальность, но обеспечение секретности не рассматривается как важное требование;

EAL2 (structurally tested) - применим при тех обстоятельствах, где разработчики или пользователи требуют средний уровень гарантированной секретности в отсутствии полной информации о всех процедурах разработки;

EAL3 (methodically tested and checked) - применим там, где разработчики или пользователи требуют средний уровень гарантированной секретности и требуют исчерпывающего исследования операционной системы и этапов ее разработки, но не прибегая к существенной переработке ОС;

EAL4 (methodically designed, tested and reviewed) - применим при тех обстоятельствах, где разработчики или пользователи требуют высокий уровень гарантированной секретности операционной системы и требует специальной доработки уже существующей ОС для обеспечения этих требований;

EAL5 (semi formally designed and tested) - применим там, где разработчики или пользователи требуют высокий уровень гарантированной секретности операционной системы и строгого подхода к проектированию, так чтобы эти свойства были заложены уже на этапе проектирования, используя специальные средства обеспечения секретности;

EAL6 (semi formally verified, designed and tested) - применим там, где существует высокий уровень опасных ситуаций и где оправданы высокие затраты на защиту от несанкционированного доступа;

EAL7 (formally verified, designed and tested) - должен применяться в приложениях с очень высокой ценой в случае несанкционированного доступа.

Уровень EAL подтверждается специальной лабораторией Common Criteria Testing Lab.

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

Система LynxOS-178

Основу LynxOS-178 составляет операционная система реального времени LynxOS v.3, которая выполняется в изолированном разделе. LynxOS v.3 сертифицирована на соответствие стандарту POSIX 1003.1-1996 на платформе Intel и PowerPC.

Ключевое свойство LynxOS-178 - поддержка нескольких полностью разделенных по времени, памяти и ресурсам разделов в соответствии с требованиями ARINC 653. LynxOS-178 (версия 2.0) поддерживает: до 16 разделов (виртуальных машин), включая корневой раздел; до 64 процессов; до 51 нити внутри каждого процесса; диспетчеризацию потоков внутри раздела в реальном времени; функции межпроцессного взаимодействия внутри раздела.

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

С помощью LynxOS-178 фиксированные разделы обслуживаются как виртуальные машины LynxOS. Каждый прикладной процесс оперирует внутри его собственной среды операционной системы, как если бы он работал на своем собственном процессоре. Это применимо ко всем ресурсам процессора и именованным пространствам. Эта абстракция защищает разработчика прикладной системы от дополнительных усилий при программировании сложной системы. Управление разделами контролируется с помощью Таблицы конфигурации виртуальных машин (Virtual-Machine Configuration Table, VCT) и является обязательным в среде LynxOS-178, позволяя разработчику приложений сконцентрироваться на разработке приложений, а не на организации разделения системы. Кроме того, LynxOS-178 поддерживает разделение систем, совместимых с RTCA DO-255, что разрешает выполнять программное обеспечение с различными уровнями безопасности по DO-178B в разных разделах (виртуальных машинах). Это означает, что операционная система может выполнять приложение с уровнем A (по DO-178B) на одной виртуальной машине и приложение с уровнем C на другой, причем оба приложения работают на одном и том же процессоре в рамках одной и той же системы.

Версия LynxOS-178 в составе различных изделий (например, самолет Bombardier Challenger 300 компании Rockwell Collins) сертифицирована по стандарту DO-178B, а архитектура самой операционной системы (рис. 3 ) соответствует требованиям ARINC 653.

LynxOS-178 обеспечивает следующие группы системных сервисов в соответствии с ARINC 653: Partition Management - управление разделами, Process Management - управление процессами, Time Management - управление временем, Interpartition Communication - взаимодействие процессов в различных разделах (Sampling Port Services и Queuing Port Services), Intrapartition Communication - взаимодействие процессов внутри одного раздела (Buffer Services, Blackboard Services, Semaphore Services, Event Services), Health Monitoring - контроль работоспособности операционной системы или оборудования.

В 2006 году должен быть выпущен прототип операционной системы, отвечающий EAL7; разрабатывается новое ядро LynxSecure, совместимое с требованиями MILS, которое будет содержать всего 8 тыс. строк исходного кода и будет соответствовать требованиям EAL7.

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

Литература

1. 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.
2. 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.
3. 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.
4. Evaluation of real time operating systems - the role of standards. Avionic Systems Standardization Committee (ASSC), Doc No: ASSC/330/2/141, March 1997.
5. G. Mayers, The art of Software Testing. John Wiley & Sons, 1979.
6. COTS Security Protection Profile - Operating Systems (CSPP-OS), NISTIR 6985, April 2003.
7. Common Criteria for Information Technology Security Evaluation. Part 3: Security Assurance Requirements. August 1999, Version 2.1, CCIMB-99-033.

Сергей Золотарев ([email protected]) - сотрудник компании «РТСофт» (Москва).

Дозаправщик стратегических бомбардировщиков дальнего действия KC-135 Stratotanker было решено модернизировать, чтобы обеспечить соответствие международным нормативам Global Air Traffic Management и требованиям стандарта DO-178B. Аппаратура Integrated Processing Center, разработанная компанией Rockwell Collins, предоставляет вычислительные и сетевые функции, которые могут использоваться для выполнения множества различных задач (обеспечение миссии, управление полетом, поддержка дисплеев). Базовая функциональность расширяется, что позволяет реализовывать дополнительные приложения. Обмен данными с другим оборудованием осуществляется по «авиационной» версии сети Ethernet. Внутри Integrated Processing Center имеется несколько сменных линейных модулей Line Replaceable Module. Сертифицированная операционная система реального времени LynxOS-178 работает на вычислительном модуле Common Computing Module и на концентраторе ввода-вывода Input/Output Concentrator Module.

Самолет-танкер KC-767, в котором также работает операционная система LynxOS-178, готов вывести воздушную заправку в ВВС США на новый уровень и отправить на покой старые заправщики KC-135E, состоящие на вооружении уже более четырех десятилетий. Новое судно не только вместительнее, но и надежнее, что делает его пригодным для более широкого круга операций. Фактически KC-767 - это четыре разных самолета в одном. Ярус, где находится кабина экипажа, легко оборудуется для перевозки пассажиров или грузов без ущерба для функциональности танкера. Причем можно сделать и так, чтобы в зависимости от ситуации судно было то пассажирским, то грузовым, то перевозчиком смешанного типа.

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

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

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

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

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

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

Микушов Ю. В.

[email protected]

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

Йошкар-Ола

●Введение

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

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

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

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

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

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

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

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

●Применение

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

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

●Заключение

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

Введение

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

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

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

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

Определения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Windows XP (Windows NT 5.1)

Windows Vista (Windows NT 6.0)

Windows 7 (Windows NT 6.1)

Windows 8 (Windows NT 6.2)

Windows 10 (Windows NT 10)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Типы задач

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Особенности

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Благодаря развитию вычислительной техники в последнее время стало возможным возложить на один модуль задачи, выполняемые ранее несколькими процессорными модулями, при этом улучшив массогабаритные характеристики системы управления и снизив ее стоимость. Такая тенденция в авиационной технике привела к появлению концепции интегрированной модульной авионики — ИМА (Integrated Modular Avionics, IMA).

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

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

Документы, регламентирующие требования к ОСРВ

• Стандарт DO-178 (Software Consideration in Airborne Systems and Equipment Certification) определяет требования к процессу разработки программного обеспечения и тщательности его проверки в зависимости от его уровня критичности. Уровень критичности ПО определяется на основе анализа серьезности последствий отказа в ПО. Всего предусмотрено пять уровней критичности ПО (от A до E).
• MILS (Multiple Independent Levels of Secutiry) представляет собой специальный подход к проектированию ОС, препятствующий распространению ошибок прикладного программного обеспечения во время выполнения, а также упрощающий верификацию программ за счет модульности ПО. Все приложения помещаются в так называемые разделы (partitions). Разделы имеют выделенные ресурсы (область памяти, процессорное время в течение каждого цикла системы, доступ к каналам обмена и пр). Доступ к выделенным ресурсам гарантируется ОС, работающей в режиме супервизора. Таким образом, на одном процессорном модуле под управлением одной ОС может работать прикладное ПО разного уровня критичности — если сбой произойдет в менее критичном (и, соответственно, менее проверенном) ПО, это никак не повлияет на работу других разделов, так как попытки «узурпировать» чужие ресурсы будут пресечены операционной системой. Идеи MILS перекликаются с идеями ИМА и DO-178B .
• Стандарт ARINC-653 (Avionics Application Software Standard Interface) специфицирует интерфейс прикладного программного обеспечения APEX, поддерживающий концепцию разделов в духе MILS. Данный интерфейс включает функции управления разделами, процессами, разделением времени, коммуникациями между разделами и внутри раздела, мониторинг состояния системы. Надо отметить, что стандарт ARINC-653 описывает общепризнанный подход к реализации идей MILS для ИМА, хотя могут быть и другие реализации. Авиационная ОСРВ, соответствующая ARINC-653 , имеет преимущества, так как данный стандарт хорошо известен и понятен международным сертифицирующим органам, поэтому на систему, построенную по этому стандарту, проще получить сертификат соответствия DO-178B .
• Стандарт Reusable Software Components. В соответствии с DO-178B программное обеспечение той или иной системы авиационного применения проходит процедуру сертификации полностью, даже если оно использует модули (компоненты), которые уже были сертифицированы ранее в составе другой системы. Одной из последних инициатив FAA (Федеральное агентство по сертификации гражданской авиации, США) является определение критериев возможности многократного использования ПО без повторной сертификации. Компоненты, которые можно повторно не сертифицировать, называются RSC (Reusable Software Components). Чтобы получить сертификат на RSC, нужно затратить больше усилий, но затем RSC дает серьезную экономию.

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

• ГОСТ Р ИСО/МЭК 51904—2002 («ПО встроенных систем. Общие требования к разработке и документированию») — аналог DO-178B для военной авиации;
• КТ-178А («Квалификационные требования часть 178А») — аналог DO-178B для гражданской авиации;
• ГОСТ Р ИСО/МЭК 12207—99 («Информационная технология. Процессы жизненного цикла программных средств»).

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

Временные параметры ОС

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

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

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

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

Достаточно объективными данными можно считать результаты, полученные экспертами журнала Dedicated System, проводившими тестирование и практическое сравнение QNX RTOS 6.1, VxWorks AE 1.1 и Windows CE.NET на x86 платформе. Хотя на сегодняшний момент эти данные устарели, авторам данной статьи не удалось найти более свежего материала. В табл. 2 приведены выборочные данные о сравнении производительности QNX Neutrino 6.1, VxWorks AE 1.1. В отчете Dedicated Systems предпочтение с точки зрения быстродействия было отдано QNX, причем отношение баллов было установлено как 9:5 (QNX:VxWorks), потому как в процессе тестирования в VxWorks были обнаружены две ошибки, за исправлением которых пришлось обращаться в службу поддержки.

В табл. 3 приведены данные о характеристиках LynxOS. Состав использовавшихся тестов не указан. В качестве данных о характеристиках LynxOS интересна четвертая колонка (тестирование на x86-платформе). По сравнению с VxWorks и QNX, ОС РВ LynxOS показывает огромную задержку при реакции на прерывание (более чем в 5 раз). Время переключения контекста (имеется в виду время переключения между двумя потоками в одном процессе) одинаковое с QNX и меньше примерно в 1,5 раза, чем у VxWorks.

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

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

Исходя из данных журнала Dedicated System, QNX опережает по этому критерию VxWorks как по разбросу характеристик в серии однотипных тестов (отношение максимума времени к среднему значению существенно меньше), так и с ростом нагрузки (время переключения потока при увеличении числа потоков 2…128 ед. у QNX выросло только в 1,65 раза, тогда как у VxWorks — в 2,24 раза).

По данным, полученным в компании РТСофт, известно, что LynxOS имеет приблизительно те же характеристики, что VxWorks.

Управление доступом к ресурсам

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

Первый вопрос, на который нужно найти ответ — поддерживает ли ОС модель процессов. Процесс — это логический объект, который владеет одним или несколькими потоками, ассоциированными с ними ресурсами и контекстом — содержимым регистров и счетчиков в каждый отдельный момент времени.

Задача процессов состоит:

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

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

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

Поддержка мультипроцессорных и распределенных систем

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

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

ОС РВ QNX предлагает поддержку многопроцессорных плат. Для VxWorks такая поддержка пока только анонсирована. Авиационной версии LynxOS с поддержкой многопроцессорных плат пока тоже не существует.

В отношении поддержки сетевых протоколов нужно отметить, что ОС РВ LynxOS, VxWorks и QNX обладают примерно равными (и широкими) возможностями. Дополнительным плюсом ОС РВ QNX является ее специальная архитектура сетевой подсистемы, обеспечивающая сетевую «прозрачность» прикладных программ: любой процесс может вызвать другой процесс на удаленном модуле так же, как и процесс на локальном модуле.

Поддержка файловых систем

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

В табл. 4 показана поддержка файловых систем каждой из рассматриваемых ОС.

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

Качество документации

Качество документации ОС РВ LynxOS, VxWorks, QNX достаточно высокое. Однако есть и нарекания по поводу документации:

• QNX — отличное описание архитектуры и принципов построения, но недостаточное описание интерфейса прикладного программирования (дано описание не всем параметрам, есть несоответствия);
• VxWorks — нет объяснения принципов работы и недостаточное описание сложного процесса конфигурирования ОС.

Тем не менее, компании работают над качеством материала. Документация на текущую версию QNX (6.3.2) существенно расширена, налицо переработка некоторых частей.

Качество технической поддержки

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

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

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

Открытость исходных кодов

Открытая ОС РВ имеет по крайней мере три преимущества:

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

С сентября 2007 года компания QSS открыла исходные коды ядра QNX (включая пакет сегментирования Adaptive Partitioning, пакет высокой готовности High Availability). Немногим позже были открыты исходные коды сетевой подсистемы. В настоящее время на официальном сайте доступна для скачивания бета-версия 6.4.0.

Надо отметить, что на сегодняшний день не все модули QNX открыты (например, нет кодов для графической и файловой систем), и лицензия налагает ограничение на использование «исходников»: только для некоммерческого применения. Тем не менее, пользователь QNX получает указанные выше преимущества бесплатно.

Исходные коды LynxOS и VxWorks доступны в продаже. Цена на такой продукт договорная.

Инструментальные средства

Наличие хороших инструментальных средств во многом определяет качество и скорость разработки прикладных программ под ту или иную ОС. Надо отметить, что LynxOS, VxWorks и QNX в настоящее время предоставляют хорошего качества инструментальные средства, которые включают интегрированную среду разработки (ИСР) и отладки прикладного ПО, средства профилирования программ (для обнаружения «узких мест» по производительности, памяти и пр.). Эргономика ИСР для данных ОС РВ в целом не уступает развитым средствам разработки для обычных ОС (например, MS Windows).

Переносимость прикладного ПО

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

Возможность написания переносимого ПО определяется в текущий момент соответствием стандарту POSIX. Все рассматриваемые ОС РВ поддерживают стандарт POSIX 1003.1. Преимущество есть у LynxOS — данная ОС обладает бинарной совместимостью с ОС Linux. То есть приложения Linux могут быть запущены под LynxOS без перекомпилирования. И, наоборот, приложения LynxOS могут быть запущены в Linux (версии 2.4.x c библиотекой языка Си glibs версии 2.2.2).

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

Поддержка процессорных архитектур

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

Соответствие авиационным стандартам

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

LynxOS в части соответствия стандартам является лидером. Она поддерживает ARINC-653 , существует достаточно много примеров систем, сертифицированных по DO-178B , построенных на ее основе. Ключевым моментом является то, что компания LynuxWorks предлагает набор RSC (правда, авторам статьи ничего не известно о цене).

VxWorks соответствует стандарту ARINC-653 , и системы, построенные на ее основе, могут быть сертифицированы по DO-178B (существует большое количество примеров).

QNX не соответствует ARINC-653 , и пока не существует систем на их основе, сертифицированных по DO-178B .

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

В части аналогичных российских стандартов для военной авиации (ГОСТ Р ИСО/МЭК 51904—2002) нет еще ни одного примера сертифицированной системы, хотя принципиально на основе любой из рассматриваемых ОС можно такую систему разработать. Для ОС РВ QNX в настоящее время ведется работа по подготовке основных модулей ОС к сертификации.

Развитость системы подготовки специалистов

Быстрота и качество обучения персонала, работающего с ОС РВ и различными инструментариями по разработке и отладке ПО, напрямую связано со скоростью разработки ПО и его качеством. Ведущие компании в области встроенного и системного ПО, такие как WindRiver, LynuxWorks, QSS, проводят широкомасштабную программу курсов и тренингов по изучению использования продуктов компании, в том числе и ОС РВ.

Результаты сравнения

ОСРВ QNX Neutrino является наиболее совершенной ОС с технической точки зрения, располагает хорошим набором инструментальных средств, имеет относительно невысокую цену. Микроядерная архитектура обеспечивает высокую надежность и модульность разрабатываемых систем. Дополнительным плюсом является открытость исходных кодов. Но есть и «ложка дегтя»: в настоящее время QNX практически нигде не используется в авиации, и по этому параметру данная ОС проигрывает конкурентам (LynxOS и VxWorks). Дополнительный минус QNX: несоответствие стандарту ARINC-653 .

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

Работа по подготовке к сертификации QNX Neutrino по требованиям отечественных авиационных стандартов в настоящее время ведется компанией SWD Software.

ОСРВ LynxOS-178 , напротив, имеет все необходимые сертификаты за рубежом, хотя по многим другим критериям выглядит менее предпочтительно, чем QNX Neutrino. Отметим, что для применения в российской авиационной промышленности ОСРВ LynxOS-178 также должна быть сертифицирована по отечественным ГОСТ.

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