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

Стандарт 1003.1b (Realtime Extensions) содержит расширения стандарта относящиеся к поддержке реального времени. К ним относятся:

-сигналы реального времени;

-планирование выполнения (с учетом приоритетов, циклическое планирование);

-таймеры;

-синхронный и асинхронный ввод/вывод;

-ввод/вывод с приоритетами;

-синхронизация файлов;

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

       Для соответствия стандарту  POSIX, ОС должна реализовать не менее 32 уровней приоритетов для процессов. POSIX определяет три основных политики диспетчеризации и планирования исполнения процессов:

-SCHED_FIFO – процессы обрабатываются порядке поступления в очередь исполнения и выполняются до полного завершения;

-SCHED_RR – round robin – циклическое планирование - данная дисциплина выделяет каждому текущему процессу, готовому для исполнения, квант времени по окончании которого процесс принудительно прерывается и помещается в конец очереди исполнения;

НЕ нашли? Не то? Что вы ищете?

-SCHED_OTHER – планирование процессов, использующее SCHED_OTHER, является реализационно-зависимым и не является переносимым между платформами.

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

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

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

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

DO-178B

Стандарт DO-178B (Software Considerations in Airborne Systems and Equipment Certification), был разработан рабочей группой Радиотехнической комиссии по аэронавтике (RTCA, Radio Technical Commission for Aeronautics) для разработки ПО бортовых авиационных систем и утвержден в своей референсной версии в январе 1992 года. В январе 2012 была принята DO-178C, причиной этому послужила необходимость пересмотра довольно старого на текущий момент DO-178B в соответствии с текущим развитием информационных технологий и программного обеспечения. Стандартом предусмотрено пять уровней описания степени серьезности отказа, и для каждого из данных уровней определен набор требований к программному обеспечению, которые должны гарантировать работоспособность всей системы в целом при возникновении отказов данного уровня отказа. Данный стандарт основывается на методе оценки опасности, которую может вызвать неправильная работы системы в первую очередь для пассажиров и экипажа воздушного судна, и определяет следующие уровни сертификации:

- А (катастрофический) данный отказ может привести к множественным человеческим жертвам, и потере воздушного судна. Дальнейший полет и приземление при данном отказе невозможны;

- В (опасный) – отказ имеет большое негативное воздействие на производительность и  работоспособность системы, что может привести к человеческим жертвам;

- С (существенный) отказ существенно уменьшает запас надежности и приводит к увеличению роли человека в управлении, что может привести к жертвам или травмам;

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

- Е (не влияющий) отказ никак не влияет на безопасность работы системы.

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


ARINC-653

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

ARINC 653 входит в серию 600 стандартов ARINC. В данной серии определены стандарты на цифровую авионику. В 2006 г. Была принята новая редакция этого стандарта.

ARINC-653 в качестве одного из основных требований к ОСРВ в авиационной промышленности вводит понятие изолированных (partitioning) виртуальных машин.  В 2007 году было выпущено очередное дополнение стандарта. Оно касается организации холодного и горячего старта модулей авионики, стандартов обработки ошибок приложениями. В настоящее время стандарт расширен еще четырьмя дополнениями: базовые сервисы, дополнительные сервисы, порядок сертификации, подмножества сервисов.


Обзор современных ОСРВ

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

-VxWorks;

-QNX;

-RTEMS;

-RT-Preempt Linux.


VxWorks

VxWorks является операционной системой реального времени, рассчитанной на применение в качестве встраиваемой системы. Первая версия вышла в 1987 году и с тех пор система продолжает совершенствоваться.

Особенности системы:

-Поддержка вытесняющей многозадачности и циклической многозадачности;

-Быстрая обработка прерываний;

-Приложения пользовательского уровня могут выполняться в изолированной от других приложений среде при помощи механизма защиты встроенного в ядро;

-Поддержка симметричного и ассиметричного мультипроцессирования ;

-Бинарные, счетные и взаимоисключающие семафоры с поддержкой наследования приоритетов;

-Поддержка частных и глобальных очередей сообщений;

-POSIX совместимая система;

-Поддержка файловых систем HRFS, FAT, NFS;

-Поддержка стека протоколов TCP/IP;

-Неограниченное количество запускаемых задач ;

-256 приоритетов для задач;

-Детерменированное время переключение контекста ;

-Поддержка большого количества оборудования.

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

В настоящее время VxWorks перенесен на множество архитектур и в их числе:

-x86;

-MIPS;

-PowerPC ;

-Freescale ColdFire ;

-Intel i960 ;

-SPARC;

-Fujitsu FR-V;

-SH-4.

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

Из за большого объема этот материал размещен на нескольких страницах:
1 2 3 4 5 6 7 8 9 10 11