Разработка бортового программного обеспечения космического аппарата

Размещено на http://www.allbest.ru/

Оглавление

Введение

1. Постановка задачи. Обзор работы КА. Обзор ОСРВ

1.1 Аппаратные средства малых КА, бортовые шины передачи данных, радиолинии

1.1.1 Шины передачи данных

1.1.2 Система энергоснабжения

1.1.3 БВС

1.1.4 Командная радиолиния

1.2 Технологический цикл управления КА

1.3 ОСРВ их виды, механизмы, обзор рынка современных ОСРВ

1.4 Процессы, потоки, задачи

1.5 Память

1.6 Прерывания

1.7 Часы и таймеры

1.8 Стандарты ОСРВ

1.8.1 POSIX

1.8.2 DO-178B

1.8.3 ARINC-653

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

1.9.1 VxWorks

1.9.2 RTEMS

1.9.3 QNX

1.9.4 RT-Preempt-Linux

1.10 Инструментальные средства для программирования под ОСРВ

1.11 Сравнение выбранных операционных систем

2. Разработка бортового программного обеспечения

2.1 Архитектура бортового ПО

2.2 Межзадачное взаимодействие и информационный обмен по шинам передачи данных

2.3 Живучесть - парирование отказов

2.4 Возможности для развития и модернизации

2.5 Тестирование и отработка бортового ПО

2.6 Документирование проекта

Заключение

Список сокращений

Список источников



Введение

бортовой программный космический время

XX век стал веком освоения космического пространства. После достижения сугубо военной цели - доставки ядерного заряда в любую точку поверхности земного шара - инженеры и ученые устремили свой взгляд в неосвоенные еще человеком области природы - околоземное космическое пространство, Солнечную систему и Вселенную. Начиная с простейших искусственных спутников Земли, в настоящее время свою службу на различных орбитах несут сотни космических аппаратов (КА) различного назначения. Именно благодаря освоению космоса стала возможной спутниковая навигация, глобальное картографирование, ретрансляция сигналов между континентами, точное предсказание погоды и получение принципиально новых знаний в фундаментальных областях науки. Усложнение космической техники и задач, которые решаются с ее использованием, потребовало в свою очередь усложнения и совершенствования вычислительных средств как наземных - для баллистических расчетов и расчетов конструкции, аппаратно-программного моделирования, оперативного управления, так и бортовых средств - средств обеспечивающих целевое назначение КА. Долгое время считалось, что космическая техника должна функционировать по строго расписанным циклограммам работы и управляться разовыми командами. Циклограммы, составленные и выверенные на Земле, и заложенные на борт направляли космическую ракету в плоскости выведения и плоскостях дальнейших орбит, управляли поведением КА, включением и выключением его аппаратуры, переориентацией. В настоящее время данный подход существенно дополнен гибкой функциональностью, предоставляемой бортовыми вычислителями. Циклограммы являются удобным механизмом для выполнения заранее определенной последовательности действий с определенными временными интервалами, но с развитием вычислительной техники на смену системам с жесткой логикой пришли системы управления, построенные на основе цифровых вычислительных машин (ЦВМ). Система управления, построенная на основе бортовой ЦВМ, является гибким и надежным механизмом реализации целевого назначения космической техники. Среди множества задач решаемых БЦВМ, задачи обработки информации, принятия решений и формирования команд управления занимают центральное место и определяют всю специфику работы управляющей системы КА.

На начальной стадии внедрения БЦВМ в космическую технику, различные системы КА, как правило, имели свои автономные вычислительные устройства. Даже качественный анализ позволяет сделать вывод о том, что основным недостатком подобной организации вычислительных средств является ее низкая эффективность. Существует много бортовых задач, решаемых эпизодически или с большим временным интервалом. При решении таких задач коэффициент использования автономной БЦВМ оказывается очень низким[1].

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

Процессы, происходящие при полете КА, являются скоротечными, часто непредсказуемыми, и требуют своевременной реакции. Помимо этого запланированные операции управления требуют высокой точности исполнения. Современное развитие аппаратных и программных средств БЦВС позволяет удовлетворить противоречивые требования задач управления бортовой аппаратурой и обеспечить целевое применение КА в процессе эксплуатации.

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

1. Постановка задачи. Обзор работы КА. Обзор ОСРВ.

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

-предоставления богатого набора высокоуровневых языков программирования, как минимум включающую реализацию ANSI C, C++ компиляторов, и обладающих высокой эффективностью генерации исполняемого кода;

-поддержки международных стандартов организации систем реального времени, как минимум POSIX 1003;

-многоплатформенность исполнения;

-предоставления богатым инструментарием кроссплатформенной разработки и отладки ПО;

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

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

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

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

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

Основными задачами БКУ являются:

-Управление движением центра масс КА;

-Получение и обработка навигационной информации;

-Командно-логическое управление служебными системами и целевым оборудованием;

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

Система ориентации и стабилизации (COC) представляет из себя совокупность аппаратных и программных средств обеспечивающих ориентацию КА вокруг центра масс. От корректности работы СОС во многом зависит возможность его использования по целевому назначению. К основным задачам СОС относятся:

-Гашение угловых скоростей (успокоение) после отделения КА от ракеты-носителя;

-Построение и поддержание ориентации связанных осей КА относительно опорных систем координат (стабилизация);

-Выполнение программных поворотов;

-Определение и прогноз навигационных параметров;

-Взаимодействие с аппаратурой спутниковой навигации (АСН).

Группа задач обеспечения взаимодействия с НКУ:

-Организация информационно-командной связи с НКУ;

-Ввод и обработка командно-программной информации;

-Ввод и обработка разовых (релейных) команд;

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

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

КА “Канопус-В” разработан как аппарат дистанционного зондирования Земли, поэтому одним из наиболее важных критериев оценки качества функционирования системы ориентации и стабилизации являются точность наведения на объект съёмки и качество стабилизации целевой аппаратуры в процессе получения изображения. Для обеспечения точного наведения на цель съемки необходимо иметь на борту комплекс задач навигационно-баллистического обеспечения, способный эффективно прогнозировать положение центра масс КА в пространстве, а также уточнять навигационные параметры по данным от аппаратуры спутниковой навигации, а также обрабатывать данные, получаемые от системы астронавигации для определения ориентации связанных осей КА выбранной системы координат.

Для обеспечения выполнения целевой задачи по получению фотографических изображений Земной поверхности для КА «Канопус-В» была выбрана солнечно-синхронная орбита[32]. Данная орбита обеспечивает приблизительно одинаковую освещенность поверхности Земли над которой пролетает ИСЗ[11]. Космический аппарат, находящийся на солнечно-синхронной орбите большую часть своего активного существования находится в автономном полете, вне зоны радиовидимости наземных командно-измерительных пунктов, и должен исполнять заложенные на борт в сеансах связи программы съемок и управления бортовой аппаратурой.

При разработке ПО особое внимание было уделено решению задачи взаимодействия с НКУ. Данное взаимодействие является единственным способом наблюдения и управления.

1.1 Аппаратные средства малых КА, бортовые шины передачи данных, радиолинии

Современные КА в зависимости от их целевого назначения имеют разнообразный набор аппаратных средств. Тем не менее, основной состав систем, обеспечивающих жизнедеятельность КА, остается общим. К нему относятся[11]:

-система энергоснабжения;

-командная радиолиния;

-исполнительные органы (двигатели-маховики, реактивные двигатели, магнитные катушки, гравитационные штанги и т.п.) системы ориентации;

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

-система обеспечения температурного режима.

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

-необходимая точность работы системы ориентации;

-требуемые режимы ориентации;

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

-энерговооруженность;

-состав комплекса бортовых обслуживающих систем.

Представляющий наибольший прикладной интерес с точки зрения реализации результатов данной НИР КА «Канопус-В» относится к классу малых массогабаритных КА дистанционного зондирования Земли. Для выполнения данной целевой задачи КА требуется осуществлять очень точное поддержание заданной ориентации для недопущения искажения получаемых снимков подстилающей поверхности. Для обеспечения выполнения этих требований на этапе штатной работы для определения и поддержания ориентации КА используется система астронавигации совместно с малоинерционными двигателями маховиками, позволяющими осуществлять поддержание точной стабилизации КА с минимальными возмущениями[32].

1.1.1 Шины передачи данных

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

-высокая пропускная способность;

-магистральный принцип обмена;

-высокая достоверность передачи информации;

-высокая помехозащищенность и гальваническая развязка;

-минимизация связей (сложности топологии) и, соответственно, массы;

-резервирование;

-высокая степень отработанности, в том числе летные испытания экспериментальных образцов вне бортового комплекса управления;

-серийность элементной базы;

-стандартизация (в том числе международная) интерфейса ввода-вывода.

Одними из наиболее распространенных и, соответственно, отработанных являются шины CAN и 1553B (МКО). Основными особенностями мультиплексного канала обмена 1553B являются[17]:

-магистральный принцип построения;

-командно-ответный принцип обмена;

-число абонентов сети - 32;

-магистраль, выполненная в виде экранированной пары витой пары проводов, протяженностью до 100 метров;

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

-стандартизация (ГОСТ Р 52070-2003, MIL-STD-1553B, STANAG 3838 AVS) форматов обмена, содержимого служебных слов и логики управления каналами;

В свою очередь шина CAN обладает следующими особенностями[28]:

-возможность работы в режиме жестко реального времени;

-простота реализации;

-арбитраж сети без потери пропускной способности;

-высокая устойчивость к помехам;

-надежный контроль ошибок передачи и приема;

-является широковещательным одноранговым последовательным интерфейсом;

-стандартизация форматов обмена ISO 11898;

-количество абонентов для версии 2.0А - 2048;

-широкий диапазон скоростей работы;

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

-при скорости передачи данных 500кб\сек протяженность магистрали 100 метров.

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

1.1.2 Система энергоснабжения

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

1.1.3 БВС

На КА «Канопус-В» используется схема с ненагруженным резервированием большинства модулей авионики и нагруженным («теплым») резервирование БВС. «Теплое» резервирование БВС означает, что от момента отделения он разгонного блока ракеты-носителя на резервную БВС подано питание, но она находится в неактивном состоянии до тех пор, пока основная машина управляет КА. Это означает, что при отказе основной БВС, резервная БВС берет управление на себя и начинает производить операции по парированию сбоев, а также выборе необходимого комплекта оборудования[32].

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

Рис.1.1 - Схема бортовой информационной сети КА

Бортовая вычислительная система КА "Канопус-В" содержит два вычислительных модуля, построенных на процессоре архитектуры SPARC, с тактовой частотой 14 мегагерц, объемом оперативной памяти 4 мегабайта и содержащей блоки энергонезависимой памяти объемом 1 мегабайт[32]. Скромные по сравнению с ПК аппаратные ресурсы накладывают жесткие ограничения на выбор операционной системы и требуют реализации наиболее эффективных и одновременно наименее ресурсоемких алгоритмов бортового ПО.

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

1.1.4 Командная радиолиния

Командная радиолиния космического аппарата (КРЛ) необходима для возможности взаимодействия борового и наземного комплексов управления. К ней предъявляются жесткие требования по обеспечению достоверности передаваемой информации и команд (сообщений). С этой целью используется помехоустойчивое кодирование. От реализации методов достоверности передачи данных зависит качество принимаемой на НКУ телеметрической информации. КРЛ должна обеспечить передачу достаточного для анализа и принятия решения по управлению объема телеметрической информации с космического аппарата, при этом обеспечивая прием и первичную проверку управляющих воздействий, с целью недопущения искажений передаваемых управляющих воздействий. Современные командные радиолинии построены на совместном использовании релейных\разовых команд (РК) и блоков командно-программной информации (КПИ). Релейные команды исполняются в блоке разовых команд (бортовом дешифраторе), выходы которого подключены напрямую (в обход бортовой вычислительной системы) к различному бортовому оборудованию. В качестве примера можно привести РК включения передатчика командной радиолинии, перезапуск бортовой вычислительной системы, включение системы обеспечения теплового режима и т.д. КПИ, напротив, могут быть приняты и обработаны только с использованием бортовой вычислительной системы. Количество и формат КПИ зависит от решаемых КА целевых задач, и от концепции спроектированного бортового комплекса управления. В качестве примера информации, передаваемой при помощи различных типов КПИ можно привести:

-установку текущего бортового времени

-выдачу управляющих воздействий с абсолютной привязкой к временной шкале

-задание начальных условий движения для баллистических расчетов

-прием и запись модификаций ПО и т.д.

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

1.2 Технологический цикл управления КА

Космический аппарат является объектом управления с большим автономным сроком работы. От момента отделения от разгонного блока ракеты носителя, до вывода аппарата из строя система управления КА должна постоянно выполнять возложенные на нее функции по обеспечению, как жизнедеятельности КА, так и по обеспечению выполнения целевых задач. В зависимости от состояния КА может находиться в следующих режимах[18]:

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

-сеансном. Режим, при котором космический аппарат взаимодействует с наземным комплексом управления. В сеансном режиме на Землю отправляется записанная ранее (или получаемая непосредственно в сеансе) телеметрия и принимаются команды управления;

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

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

-Произвести самоконтроль;

-Определить текущие угловые скорости вращения корпуса КА и произвести их гашение при помощи исполнительных органов системы ориентации;

-Произвести ориентирование КА на Солнце, для обеспечения наилучшего притока электроэнергии от солнечных батарей;

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

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

-Произвести инициализацию командной радиолинии;

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

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

-Активировать механизм распознавания, протоколирования и парирования нештатных ситуаций.

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

1.3 ОСРВ их виды, механизмы, обзор рынка современных ОСРВ

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

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

Основные черты «жесткой» системы (ОСРВ):

-гарантированное время реакции на внешние события (прерывания от оборудования);

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

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

Мартин Тиммерман сформулировал следующие необходимые требования для ОСРВ[9]:

-ОС должна быть многозадачной и допускать вытеснение;

-ОС должна обладать механизмом приоритезации для планирования исполнения потоков;

-ОС должна реализовывать предсказуемые механизмы синхронизации;

-ОС должна обеспечивать механизм наследования приоритетов;

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

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

Приведем перечисление основных архитектур ОСРВ:

-Монолитная архитектура. ОС определяется как набор модулей, взаимодействующих между собой внутри ядра системы и предоставляющих прикладному ПО входные интерфейсы для обращений к аппаратуре. Основной недостаток этого принципа построения ОС заключается в плохой предсказуемости её поведения, вызванной сложным взаимодействием модулей между собой, а также крайне плохая масштабируемость и отсутствие возможности изменения поведения системы на лету. При монолитной структуре построения ОС состоит из набора модулей, и изменения в одном из модулей способны оказать влияние на систему в целом. Сложность эксплуатации системы растет прямо пропорционально количеству используемых модулей. Помимо этого, крайне сложно, а порой невозможно распределить ОС для мультипроцессорного исполнения. Главным достоинством монолитной архитектуры является ее высокая производительность[29]

Рис. 1.2 - Монолитная архитектура ОСРВ

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

Рис.1.3 - слоевая архитектура ОСРВ

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

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

-Улучшенная масштабируемость, сервисы в которых отсутствует необходимость могут быть безболезненно исключены из конфигурации системы;

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

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

Рис.1.4 - клиент-серверная архитектура ОСРВ

1.4 Процессы, потоки, задачи

Концепция многозадачности (концепция псевдопараллелизма) является одной из основополагающих для системы реального времени, исполняющейся в системе с единственным процессором, от приложений которой требуется способность обрабатывать многочисленные внешние события, происходящие асинхронно в случайные моменты времени. Понятие процесса, пришедшее из мира операционной системы UNIX, недостаточно эффективно реализуемо в многозадачной системе реального времени, поскольку процесс имеет достаточно объемный TCB - Task Control Block - управляющую структуру, включающую в себя все сведения о процессе. В ОСРВ определяется понятие новой сущности - потока, который реализуется как легковесный подпроцесс. Потоки выполняются в контексте одного процесса, благодаря чему межпоточное переключение происходит значительно быстрее, чем переключение порождающих процессов. При этом защита памяти между потоками отсутствует, что также увеличивает производительность из-за отсутствия проверок при обращениях к памяти. Потоки являются значительно более легковесными, за счет уменьшения регистрового контекста и содержимого управляющих блоков. Данные меры приводят к существенному уменьшению накладных расходов на сохранение и восстановление управляющих блоков переключаемых потоков. Таким образом, в системах реального времени процесс инкапсулирует в себе наименьшие единицы диспетчеризации - потоки. При анализе работы системы, построенной на базе ОСРВ, каждый процесс рассматривается как приложение. Систему стараются разрабатывать таким образом, чтобы минимизировать взаимодействие приложений имеющих различную природу - «жесткого» реального времени, «мягкого» реального времени, не реального времени.

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

В практических реализациях ОСРВ применяются два подхода к планированию выполнения задач - статические алгоритмы планирования (RMS - Rate Monotonic Scheduling) и динамические алгоритмы планирования (EDF - Earliest Deadline First). RMS используется при формальном обосновании условий предсказуемости системы. Для реализации описываемой дисциплины чтобы ОСРВ имело реализацию планирования на основе приоритетов прерывающих обслуживание (preemptive priority scheduling). В теории RMS приоритет назначается каждому процессу перед его стартом. Запускаемые процессы в свою очередь должны отвечать следующим требования:

-процесс должен быть завершен за отведенное время;

-процессы не имеют зависимости от хода выполнения и результатов исполнения друг друга;

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

-прерывание процесса должно происходит за ограниченное время.

При планировании RMS предпочтение отдается задачам с самыми короткими периодами выполнения. После исполнения данных процессов производится исполнения оставшихся с использованием принципа исполнения первыми наиболее коротких процессов.

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

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

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

-обеспечение выполнения процесса с наивысшим приоритетом в самую первую очередь;

-недопущение инверсии приоритетов, при которой задачи с высокими приоритетами вынуждены ожидать ресурсы, захваченные низкоприоритетными задачами.

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

В общем виде организацию процесса управления потоками и задачами можно представить на схеме:



Рис 1.5 Граф многозадачности

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

1.5 Память

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

-Модель без защиты - системное и пользовательское адресные пространства не разделены и не защищены друг от друга, используется всего два сегмента памяти: сегмент кода и сегмент данных, при этом от системы не требуется никакого специального управления памятью, также не требуется и MMU (memory management unit - устройство управления памятью - специальное аппаратное устройство для поддержки управления виртуальной памятью);

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

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

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

Одним из основополагающих требований к организации работы с памятью в системе реального времени заключается в том, что время доступа к ней должно быть детерминировано. Прямым следствием из данного требования становится запрет на использование техники выгрузки страниц и загрузки страниц по запросу с внешних устройств для процессов требующих реального времени. Поэтому системы, реализующие механизм виртуальной памяти, должны также блокировать процессы реального времени в оперативной памяти, не допуская подкачки. Итак, подкачка недопустима в ОСРВ, потому что не является предсказуемой по времени выполнения. Если системой поддерживается страничная организация памяти, соответствующее отображение страниц в физические адреса необходимо выполнить как часть контекста процесса. В противном случае появляется непредсказуемость, неприемлемая для ОСРВ. Для процессов, не являющихся процессами "жесткого" реального времени, возможно использование механизма динамического распределения памяти, однако при этом ОСРВ должна поддерживать обработку таймаута на запрос памяти, т.е. ограничение на предсказуемое время ожидания. В обычных ОС при использовании механизма сегментации памяти для борьбы с фрагментацией применяется процедура уплотнения после сборки мусора. Однако такой подход неприменим в среде реального времени, так как во время уплотнения перемещаемые задачи не могут выполняться, что ведет к потере непредсказуемости поведения системы. В этом состоит основная проблема применимости объектно-ориентированного подхода к системам реального времени. До тех пор, пока проблема уплотнения не будет решена, C++ и JAVA будут оставаться не самым лучшим выбором для систем жесткого реального времени. В системах жесткого реального времени обычно применяется статическое распределение памяти. В системах мягкого реального времени возможно динамическое распределение памяти, без виртуальной памяти и без уплотнения.

1.6 Прерывания

При описании управления прерываниями обычно различают две процедуры, а именно:

-программа обработки прерывания (ISR - interrupt servicing routine) - программа низкого уровня в ядре с ограниченными системными вызовами;

-поток обработки прерывания (IST - interrupt servicing thread) - поток уровня приложения, который управляет прерыванием, с доступом ко всем системным вызовам.

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

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

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

Рис 1.6 - Схема унифицированной архитектуры прерываний

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

1.7 Часы и таймеры

В любой ОСРВ используются различные службы ведения и выдачи времени. Операционная система отслеживает текущее время, в определенное время запускает задачи и потоки и приостанавливает их исполнение на определенные интервалы. Службы времени ОСРВ используют высокоточные аппаратные часы для своей работы. Для отсчета временных интервалов на основе часов реального времени создаются таймеры. Для каждого процесса и потока определяются объекты следящие за использованием процессорного времени. На базе данных объектов создаются таймеры, которые измеряют перерасход времени процессом или потоком, позволяя динамически выявлять программные ошибки или ошибки вычисления максимально возможного времени выполнения, а также профилировать приложение. В высоконадежных, критичных ко времени системах важно выявление ситуаций, при которых задача превышает максимально возможное время своего выполнения, так как при этом работа системы может выйти за рамки допустимого времени отклика. Таймеры контролирующие время исполнения процессов или потоков позволяют выявлять возникновение перерасхода времени и активизировать соответствующие действия по предотвращению такого поведения. Большинство ОСРВ оперируют относительным временем. Что-то происходит “до” и “после” некоторого другого события. В системе, полностью управляемой событиями, необходим часовой механизм, так как там нет квантования времени (time slicing). Однако, если нужны временные метки для некоторых событий или необходим системный вызов типа “ждать одну секунду”, тогда нужен тактовый генератор и/или таймер. Синхронизация в ОСРВ осуществляется с помощью механизма блокирования (или ожидания) до наступления некоторого события. Абсолютное время не применяется. Реализации в ОСРВ других концептуальных абстракций подобны их реализациям в традиционных ОС.

1.8 Стандарты ОСРВ

Наиболее ранним и известным стандартом ОСРВ считается стандарт POSIX (IEEE Portable Operating System Interface for Computer Environments, IEEE 1003.1). В своем первоначальном варианте стандарт POSIX был представлен в 1990 г. и был направлен на UNIX-подобные системы, первые версии которых были разработаны в 70-х годах двадцатого века. Спецификации POSIX регламентируют механизмы определяющие взаимодействие прикладного программного обеспечения и операционной системы. На данный момент спецификации POSIX насчитывают более чем 30 специализированных стандартов. К стандартам ОСРВ относятся семь спецификаций (1003.1a, 1003.1b, 1003.1c, 1003.1d, 1003.1j, 1003.21, 1003.2h), но широкую поддержку в распространенных ОСРВ приобрели только 1003.1a, 1003.1b, 1003.1c. Несмотря на некоторые явно устаревшие положения стандарта POSIX и большую востребованность обновлений методологии и механизмов стандартизации ОСРВ, значительного прогресса в этом направлении не наблюдается. Ряд представителей наиболее успешных компании, занятых разработкой ОСРВ объявляют о своем решении предложить на рассмотрение в качестве нового стандарта спецификации разрабатываемых ими ОСРВ. Так поступила TRON (the RTOS Nucleus), которая в 1987г. выпустила в свет первые ITRON спецификации - ITRON1. Далее в 1989г. она разработала и выпустила спецификации µITRON для 8- и 16- битовых микроконтроллеров, а также спецификации ITRON2 для 32-битовых процессоров. Наибольшее распространение данный формат получил в Японии. Военная и аэрокосмическая отрасли традиционно предъявляют наиболее жесткие требования к вычислительным средствам, влияющим на общий показатель безопасности целевой системы. В авиационной промышленности используются два следующих стандарта для ОСРВ - стандарт DO-178B и стандарт ARINC-653. Поскольку данные стандарты были разработаны в США, необходимо указать наличие европейского стандарта ED-12B, который, по сути, является аналогом DO-178B. Распространенным также является стандарт OSEK/VDX, который первоначально развивался для систем, используемых в автомобильной индустрии.



1.8.1 POSIX

Стандарт POSIX был разработан в качестве стандартного интерфейса сервисов операционных систем. Основным назначением стандарта является предоставление возможности разработки и создания переносимых приложений. Позднее данный стандарт был существенно дополнен специфическими для режима реального времени особенностями. Спецификации стандарта POSIX определяют стандартный механизм взаимодействия прикладного ПО и операционной системы. Исторически при своем создании и дальнейшем развитии, стандарт POSIX был тесно связан со стандартами Unix-подобных операционных систем и непосредственно с ОС UNIX. Несмотря на этот факт разработчики многих ОС, включая ОСРВ, ставят перед собой целью реализовать в своих разработках соответствие стандарту POSIX. Соответствие стандарту POSIX для ОС и аппаратной платформы должно быть сертифицировано при помощи исполнения на них набора специфических тестов. В случае если ОС не является Unix-подобной, выдержать соответствие тестовым проверкам становится чрезвычайно сложной задачей. Наборы тестовых инструкций реализованы только для POSIX 1003.1a. По причине того, что стандарт POSIX представляется совокупностью факультативных интерфейсов, реализация всего множества которых не является обязательной, разработчики ОС предпочитают реализовать только часть стандартного интерфейса. При этом появляется понятие POSIX-комплиантности системы - частичное или полное соответствии системы стандарту. Несмотря на то, что стандарт POSIX в своей основе содержит многие основополагающие принципы операционной системы Unix, он затрагивает основополагающие абстракции которые в большинстве относятся ко всем операционным системам, а расширения стандарта в части реального времени могут быть применимы к подавляющему большинству ОСРВ. В настоящее времени стандарт POSIX рассматривается как раздел взаимодополняющих стандартов: IEEE Std 1003.n (где n - это индекс).

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

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

...