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

Системы реального времени (РВ) по мере развития становятся все более сложными, в их разработке принимают участие большие коллективы. Требования к надежности систем РВ постоянно возрастают. В силу этого назрела потребность в разработке средств повышения надежности систем РВ в случае сбоев в работе прикладных программ и операционной системы (ОС). В статье рассматриваются принципы и пути построения ОС РВ Багет 3.0, которая была разработана с целью решения указанных проблем. Данная система – развитие ОС РВ Багет 2.0 [1], которая используется специалистами более 100 организаций России в течение 10 лет.

Разработка ОС РВ Багет 3.0 базируется на следующих принципах:

– разбиение системы на слабо взаимодействующие части (partitioning) с тем, чтобы сбои в одной части не влияли на работоспособность других;

– наличие средств восстановления после сбоев, а также развитые средства диагностики и обработки ошибок;

– гибкие средства планирования (периодическое, приоритетное планирование, планирование с вытеснением – preemptive scheduling);

– использование объектно-ориентированного подхода;

– управляемость (в частности, наличие средств конфигурирования).

При разработке ОС РВ использовались спецификация ARINC 653 [2] и стандарт POSIX 1003.1 [3], определяющие интерфейс прикладных программ с ОС.

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

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

Первая версия ARINC 653 вышла в 1996 году, и к настоящему времени основные фирмы-про- изводители ОС РВ уже выпустили ОС, соот- ветствующие этой спецификации: VxWORKS AE653 (Wind River) [4], LynxOS-178 2.0 (LynuxWorks, Inc.) [5], INTEGRITY-178B (Green Hills Software Inc.) [6].

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

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

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

Кроме того, в соответствии со стандартом POSIX реализованы математические функции, функции обработки символов и строк, распределения памяти и др.

Все POSIX-процессы, за исключением главного системного процесса, выполняются в пользовательском режиме процессора. Главный системный процесс выполняется в привилегированном режиме процессора.

Реализованы все функции спецификации ARINC 653, отмеченные как обязательные, а также необязательные функции управления расписаниями. Эти функции обеспечивают:

– управление процессами (partition), включая планирование;

– синхронизацию потоков управления внутри одного процесса (семафоры и события);

– передачу данных внутри одного процесса (buffer и blackboard) и по каналам;

Все ARINC-процессы выполняются в пользовательском режиме процессора.

Загрузка и порождение как POSIX-, так и ARINC-процессов в соответствии с ARINC 653 происходят только при инициализации модуля. Порождаемые процессы и выделяемые им ресурсы указываются при конфигурировании системы. По завершении этапа инициализации порождение процессов невозможно, но возможны рестарт (останов и запуск с начала) и останов ARINC-процессов. Рестарт POSIX-процессов невозможен (только вместе с рестартом модуля).

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

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

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

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

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

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

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

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

Процесс считается работоспособным, если хотя бы один его поток управления работоспособен. В каждый момент выполняется наиболее приоритетный работоспособный поток наиболее приоритетного работоспособного процесса. Если наиболее приоритетным является POSIX-процесс (процессы), то выбирается наиболее приоритетный работоспособный поток управления среди всех POSIX-процессов.

Другими словами, потоки ARINC-процессов конкурируют за процессор с другими потоками того же процесса в соответствии с приоритетами потоков. Потоки POSIX-процессов конкурируют за процессор с потоками всех POSIX-процессов в соответствии с приоритетами потоков.

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

Методы повышения надежности ОС Багет 3.0

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

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

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

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

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

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

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

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

Для отладки ОС была разработана обширная система тестов, реализующая, в частности, все требования спецификации ARINC 653 к системе тестов. Работа над системой не прекращается, к ней добавляются новые тесты, а имеющиеся совершенствуются.

Обработка ошибок в ОС Багет 3.0

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

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

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

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

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

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

Временные характеристики ОС Багет 3.0

При оценке систем РВ используются две важнейшие характеристики – время ответа на прерывание и время ответа потока управления.

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

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

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

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

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

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

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

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

Результаты измерений временных характеристик (модуль БТ23-206 с частотой 400 МГц) следующие:

· скорость передачи данных между процессами на различных модулях по шине VME – 12 Мб/сек.;

Мобильность ОС Багет 3.0

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

С целью повышения мобильности ОС она разбита на три части:

– зависящая только от типа центрального процессора,

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

восстановления контекста, пролог и эпилог диспетчера прерываний.

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

В заключение отметим, что ОС РВ Багет 3.0 – современная высоконадежная отечественная ОС с пользовательским интерфейсом, базирующимся на спецификации ARINC 653 и стандарте POSIX 1003.1, с временными характеристиками на уровне мировых стандартов. Использование ARINC 653 обеспечивает адекватный интерфейс разработчикам прикладного ПО, а наличие POSIX-процессов дает возможность с минимальными издержками переносить ПО из систем с POSIX-интерфейсом, в частности, из ОС РВ Багет 2.0.

Литература по ОС Багет 3.0

Знаете ли Вы, что cогласно релятивистской мифологии "гравитационное линзирование - это физическое явление, связанное с отклонением лучей света в поле тяжести. Гравитационные линзы обясняют образование кратных изображений одного и того же астрономического объекта (квазаров, галактик), когда на луч зрения от источника к наблюдателю попадает другая галактика или скопление галактик (собственно линза). В некоторых изображениях происходит усиление яркости оригинального источника." (Релятивисты приводят примеры искажения изображений галактик в качестве подтверждения ОТО - воздействия гравитации на свет)
При этом они забывают, что поле действия эффекта ОТО - это малые углы вблизи поверхности звезд, где на самом деле этот эффект не наблюдается (затменные двойные). Разница в шкалах явлений реального искажения изображений галактик и мифического отклонения вблизи звезд - 10¹¹ раз. Приведу аналогию. Можно говорить о воздействии поверхностного натяжения на форму капель, но нельзя серьезно говорить о силе поверхностного натяжения, как о причине океанских приливов.
Эфирная физика находит ответ на наблюдаемое явление искажения изображений галактик. Это результат нагрева эфира вблизи галактик, изменения его плотности и, следовательно, изменения скорости света на галактических расстояниях вследствие преломления света в эфире различной плотности. Подтверждением термической природы искажения изображений галактик является прямая связь этого искажения с радиоизлучением пространства, то есть эфира в этом месте, смещение спектра CMB (космическое микроволновое излучение) в данном направлении в высокочастотную область. Подробнее читайте в FAQ по эфирной физике.

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