Оглавление Введение ........................................................................................................................... 4 1. Постановка задачи. Обзор работы КА. Обзор ОСРВ. ......................................... 7 1.1. Аппаратные средства малых КА, бортовые шины передачи данных, радиолинии..................................................................................................................... 10 1.1.1. Шины передачи данных. .................................................................................. 12 1.1.2. Система энергоснабжения ............................................................................... 13 1.1.3. БВС ..................................................................................................................... 14 1.1.4. Командная радиолиния .................................................................................... 16 1.2. Технологический цикл управления КА ............................................................. 17 1.3. ОСРВ их виды, механизмы, обзор рынка современных ОСРВ ...................... 19 1.4. Процессы, потоки, задачи ................................................................................... 24 1.5. Память ................................................................................................................... 28 1.6. Прерывания .......................................................................................................... 31 1.7. Часы и таймеры .................................................................................................... 33 1.8. Стандарты ОСРВ ................................................................................................. 34 1.8.1. POSIX ................................................................................................................. 35 1.8.2. DO-178B............................................................................................................. 38 1.8.3. ARINC-653......................................................................................................... 39 1.9. Обзор современных ОСРВ .................................................................................. 40 1.9.1. VxWorks ............................................................................................................. 41 1.9.2. RTEMS ............................................................................................................... 43 1.9.3. QNX .................................................................................................................... 45 1.9.4. RT-Preempt-Linux .............................................................................................. 47 2 1.10. Инструментальные средства для программирования под ОСРВ. ............... 49 1.11. Сравнение выбранных операционных систем ............................................... 50 2. Разработка бортового программного обеспечения ............................................ 52 2.1. Архитектура бортового ПО ................................................................................ 56 2.2. Межзадачное взаимодействие и информационный обмен по шинам передачи данных ............................................................................................................................ 59 2.3. Живучесть - парирование отказов...................................................................... 64 2.4. Возможности для развития и модернизации .................................................... 66 2.5. Тестирование и отработка бортового ПО ......................................................... 67 2.6. Документирование проекта ................................................................................ 69 Заключение .................................................................................................................... 71 Список сокращений ...................................................................................................... 73 СПИСОК ИСТОЧНИКОВ ............................................................................................ 74 Приложение А ....................................................................................................... 76 Приложение Б ........................................................................................................ 77 Приложение В........................................................................................................ 78 3 Введение XX век стал веком освоения космического пространства. После достижения сугубо военной цели - доставки ядерного заряда в любую точку поверхности земного шара - инженеры и ученые устремили свой взгляд в неосвоенные еще человеком области природы - околоземное космическое пространство, Солнечную систему и Вселенную. Начиная с простейших искусственных спутников Земли, в настоящее время свою службу на различных орбитах несут сотни космических аппаратов (КА) различного назначения. Именно благодаря освоению космоса стала возможной картографирование, предсказание ретрансляция погоды и спутниковая сигналов получение навигация, между глобальное континентами, принципиально новых точное знаний в фундаментальных областях науки. Усложнение космической техники и задач, которые решаются с ее использованием, потребовало в свою очередь усложнения и совершенствования вычислительных средств как наземных - для баллистических расчетов и расчетов конструкции, аппаратно-программного моделирования, оперативного управления, так и бортовых средств - средств обеспечивающих целевое назначение КА. Долгое время считалось, что космическая техника должна функционировать по строго расписанным циклограммам работы и управляться разовыми командами. Циклограммы, составленные и выверенные на Земле, и заложенные на борт направляли космическую ракету в плоскости выведения и плоскостях дальнейших орбит, управляли поведением КА, включением и выключением его аппаратуры, переориентацией. В настоящее время данный подход существенно дополнен гибкой функциональностью, Циклограммы являются предоставляемой удобным механизмом бортовыми для вычислителями. выполнения заранее определенной последовательности действий с определенными временными интервалами, но с развитием вычислительной техники на смену системам с жесткой логикой пришли системы управления, построенные на основе цифровых 4 вычислительных машин (ЦВМ). Система управления, построенная на основе бортовой ЦВМ, является гибким и надежным механизмом реализации целевого назначения космической техники. Среди множества задач решаемых БЦВМ, задачи обработки информации, принятия решений и формирования команд управления занимают центральное место и определяют всю специфику работы управляющей системы КА. На начальной стадии внедрения БЦВМ в космическую технику, различные системы КА, как правило, имели свои автономные вычислительные устройства. Даже качественный анализ позволяет сделать вывод о том, что основным недостатком подобной организации вычислительных средств является ее низкая эффективность. Существует много бортовых задач, решаемых эпизодически или с большим временным интервалом. При решении таких задач коэффициент использования автономной БЦВМ оказывается очень низким[1]. Принципиально новой организацией вычислительных средств на борту, устраняющей указанный недостаток, явилось использование в качестве основного звена управления и обработки информации бортовой цифровой вычислительной системы (БЦВС). БЦВС строится как отказо и сбоеустойчивая система, которая обеспечивает высокую производительность, точность и надежность вычислений. Процессы, происходящие при полете КА, являются скоротечными, часто непредсказуемыми, и требуют своевременной реакции. Помимо этого запланированные операции управления требуют высокой точности исполнения. Современное развитие аппаратных и программных средств БЦВС позволяет удовлетворить противоречивые требования задач управления бортовой аппаратурой и обеспечить целевое применение КА в процессе эксплуатации. Программное обеспечение сложной бортовой системы управления может быть реализовано с использованием средств, предоставляемых операционными системами реального времени (ОСРВ). Использование ОСРВ позволяет разработчику программного обеспечения БЦВС на определенном уровне 5 разработки абстрагироваться от аппаратной части КА и сконцентрироваться на решении функциональных задач по управлению космическим аппаратом. 6 1. Постановка задачи. Обзор работы КА. Обзор ОСРВ. Провести обзор современных операционных систем реального времени. На основе анализа предоставляемых возможностей выбрать ОСРВ приемлемую для реализации бортового программного обеспечения малого массо-габаритного КА “Канопус-В” и при прочих равных условиях наиболее эффективную с точки зрения: -предоставления богатого набора высокоуровневых языков программирования, как минимум включающую реализацию ANSI C, C++ компиляторов, и обладающих высокой эффективностью генерации исполняемого кода; -поддержки международных стандартов организации систем реального времени, как минимум POSIX 1003; -многоплатформенность исполнения; -предоставления богатым инструментарием кроссплатформенной разработки и отладки ПО; -развитая поддержка основных парадигм\абстракций, используемых при решении задач автоматизации (богатство API, системных библиотек); -массовость реализации в предметных областях ракетного и космического приборостроения. Выбор операционной системы реального времени должен учитывать специфические потребности информационной организации и управления основными функциональными системами КА. Разработка бортового ПО должна включать в себя разработку общей информационной инфраструктуры, обеспечивающего интеграцию, взаимодействие и управления прикладными задачами, ПО бортового комплекса управления (БКУ), ПО системы ориентации и стабилизации (СОС), ПО взаимодействия с наземным комплексом управления (НКУ), ПО автономного навигационного комплекса и ПО 7 управления другими системами, определяющими специфику конкретного космического аппарата. Необходимо ввести понятия БКУ, СОС: Бортовой комплекс управления КА представляет собой совокупность приборов и устройств с информационным и программным обеспечением, предназначенным для управления движением центра масс КА и управления функционированием бортового оборудования, а также для взаимодействия с наземным комплексом управления. Основными задачами БКУ являются: -Управление движением центра масс КА; -Получение и обработка навигационной информации; -Командно-логическое управление служебными системами и целевым оборудованием; -Сбор, обработка и анализ контрольно-диагностической информации, принятие решения о парировании возникающих нештатных ситуаций, в том числе автоматическое управление выбором резервного комплекта оборудования, выбор наиболее безопасных режимов функционирования с учетом конкретного технического состояния бортовых систем космического аппарата. Система ориентации и стабилизации (COC) представляет из себя совокупность аппаратных и программных средств обеспечивающих ориентацию КА вокруг центра масс. От корректности работы СОС во многом зависит возможность его использования по целевому назначению. К основным задачам СОС относятся: -Гашение угловых скоростей (успокоение) после отделения КА от ракетыносителя; -Построение и поддержание ориентации связанных осей КА относительно опорных систем координат (стабилизация); -Выполнение программных поворотов; -Определение и прогноз навигационных параметров; -Взаимодействие с аппаратурой спутниковой навигации (АСН). 8 Группа задач обеспечения взаимодействия с НКУ: -Организация информационно-командной связи с НКУ; -Ввод и обработка командно-программной информации; -Ввод и обработка разовых (релейных) команд; -Сбор предварительная (оценка полноты и достоверности получаемых данных) обработка и передача телеметрической информации. Специфической особенностью малых массово-габаритных космических аппаратов является использование единой бортовой вычислительной системы для реализации функциональности БКУ, включая СОС, навигационный комплекс и обеспечение взаимодействия с НКУ. Как следствие с одной стороны архитектура бортового программного обеспечения существенным образом усложняется, однако информационное взаимодействие имеет единую, прозрачную организацию. При выборе ОСРВ и последующей разработке ПО необходимо обратить особое внимание и на возможность последующей доработки и расширения функциональности базового кода. Использование модульной структуры ПО позволяет существенно упростить решение задачи наращивания функциональности базовой платформы, безболезненное включение новых задач и комплексов за счет унифицированной, хорошо отлаженной инфраструктуры управления и информационного взаимодействия. Поэтому модульность ОСРВ будет рассматриваться одной из наиболее принципиальной характеристики рассматриваемых ОСРВ. КА “Канопус-В” разработан как аппарат дистанционного зондирования Земли, поэтому одним из наиболее важных критериев оценки качества функционирования системы ориентации и стабилизации являются точность наведения на объект съёмки и качество стабилизации целевой аппаратуры в процессе получения изображения. Для обеспечения точного наведения на цель 9 съемки необходимо иметь на борту комплекс задач навигационно- баллистического обеспечения, способный эффективно прогнозировать положение центра масс КА в пространстве, а также уточнять навигационные параметры по данным от аппаратуры спутниковой навигации, а также обрабатывать данные, получаемые от системы астронавигации для определения ориентации связанных осей КА выбранной системы координат. Для обеспечения выполнения целевой задачи по получению фотографических изображений Земной поверхности для КА «Канопус-В» была выбрана солнечно-синхронная орбита[32]. Данная орбита обеспечивает приблизительно одинаковую освещенность поверхности Земли над которой пролетает ИСЗ[11]. Космический аппарат, находящийся на солнечно-синхронной орбите большую часть своего активного существования находится в автономном полете, вне зоны радиовидимости наземных командно-измерительных пунктов, и должен исполнять заложенные на борт в сеансах связи программы съемок и управления бортовой аппаратурой. При разработке ПО особое внимание было уделено решению задачи взаимодействия с НКУ. Данное взаимодействие является единственным способом наблюдения и управления. 1.1. Аппаратные средства малых КА, бортовые шины передачи данных, радиолинии. Современные КА в зависимости от их целевого назначения имеют разнообразный набор аппаратных средств. Тем не менее, основной состав систем, обеспечивающих жизнедеятельность КА, остается общим. К нему относятся[11]: -система энергоснабжения; -командная радиолиния; 10 -исполнительные органы (двигатели-маховики, реактивные двигатели, магнитные катушки, гравитационные штанги и т.п.) системы ориентации; -чувствительные органы системы ориентации (солнечные датчики, звездные датчики, датчики угловой скорости, инфракрасная вертикаль и т.п.); -система обеспечения температурного режима. В качестве целевой аппаратуры может выступать телевизионная или фотокамера, радио-ретранслятор, научная аппаратура для фундаментальных исследований и т.д. Характером установленной на КА целевой аппаратуры и особенностями ее эксплуатации определяются основные характеристики всего КА. К таковым относятся: -необходимая точность работы системы ориентации; -требуемые режимы ориентации; -набор разовых команд управления и семантика командно-программной информации; -энерговооруженность; -состав комплекса бортовых обслуживающих систем. Представляющий наибольший прикладной интерес с точки зрения реализации результатов данной НИР КА «Канопус-В» относится к классу малых массогабаритных КА дистанционного зондирования Земли. Для выполнения данной целевой задачи КА требуется осуществлять очень точное поддержание заданной ориентации для недопущения искажения получаемых снимков подстилающей поверхности. Для обеспечения выполнения этих требований на этапе штатной работы для определения и поддержания ориентации КА используется система астронавигации совместно с малоинерционными двигателями маховиками, позволяющими осуществлять поддержание точной стабилизации КА с минимальными возмущениями[32]. 11 1.1.1. Шины передачи данных. Взаимодействие периферийных устройств КА с БВС осуществляется по цифровым или аналоговым шинам передачи данных. К шинам передачи данных использующихся в космической технике, предъявляются жесткие требования: -высокая пропускная способность; -магистральный принцип обмена; -высокая достоверность передачи информации; -высокая помехозащищенность и гальваническая развязка; -минимизация связей (сложности топологии) и, соответственно, массы; -резервирование; -высокая степень отработанности, в том числе летные испытания экспериментальных образцов вне бортового комплекса управления; -серийность элементной базы; -стандартизация (в том числе международная) интерфейса ввода-вывода. Одними из наиболее распространенных и, соответственно, отработанных являются шины CAN и 1553B (МКО). Основными особенностями мультиплексного канала обмена 1553B являются[17]: -магистральный принцип построения; -командно-ответный принцип обмена; -число абонентов сети – 32; -магистраль, выполненная в виде экранированной пары витой пары проводов, протяженностью до 100 метров; - использование манчестерского кода для кодирования информации; 12 -стандартизация (ГОСТ Р 52070-2003, MIL-STD-1553B, STANAG 3838 AVS) форматов обмена, содержимого служебных слов и логики управления каналами; В свою очередь шина CAN обладает следующими особенностями[28]: -возможность работы в режиме жестко реального времени; -простота реализации; -арбитраж сети без потери пропускной способности; -высокая устойчивость к помехам; -надежный контроль ошибок передачи и приема; -является широковещательным одноранговым последовательным интерфейсом; -стандартизация форматов обмена ISO 11898; -количество абонентов для версии 2.0А – 2048; -широкий диапазон скоростей работы; -большое распространение технологии, наличие широкого ассортимента продуктов от различных поставщиков; -при скорости передачи данных 500кб\сек протяженность магистрали 100 метров. Стандарт CAN оптимизирован для систем, в которых должны передаваться относительно небольшие объемы информации к любому или всем узлам сети. Множественный доступ с опросом состояния шины позволяет каждому узлу получить доступ к шине с учетом приоритетов. 1.1.2. Система энергоснабжения Система энергоснабжения КА выполняет функции по преобразованию солнечной энергии в электрическую, ее накопление и обеспечение ей абонентов 13 электрической сети космического аппарата. Данная система должна включать в себя защиты от коротких замыканий, а также обеспечивать контроль заряда батареи не допуская ее перезаряда и, как следствие, выхода из строя. Систему энергоснабжения строят таким образом, чтобы была предусмотрена возможность управления ключами питания как с использованием БВС, так и напрямую, с использованием разовых команд. Это позволяет производить работы по аварийному снятию и подаче питания на выбранные устройства в обход БВС, например в случае ее выхода из строя. 1.1.3. БВС На КА «Канопус-В» используется схема с ненагруженным резервированием большинства модулей авионики и нагруженным («теплым») резервирование БВС. «Теплое» резервирование БВС означает, что от момента отделения он разгонного блока ракеты-носителя на резервную БВС подано питание, но она находится в неактивном состоянии до тех пор, пока основная машина управляет КА. Это означает, что при отказе основной БВС, резервная БВС берет управление на себя и начинает производить операции по парированию сбоев, а также выборе необходимого комплекта оборудования[32]. Взаимодействие БВС с блоками авионики выполнено в цифровом формате с использованием шин МКО и CAN. Информационный обмен осуществляется на основе заранее разработанных и согласованных протоколов информационного обмена. Обе шины и МКО и CAN построены по резервированной схеме обмена. Абоненты, требующие временной детерминированности информационного взаимодействия являются абонентами шины МКО. Для устройств, не требующих жесткой привязки ко времени при передаче данных, может использоваться шина CAN, задержка по передаче данных в которой может быть регламентирована на пользовательском (прикладном) уровне архитектуры программного обеспечения. 14 Рис.1.1 - Схема бортовой информационной сети КА Бортовая вычислительная вычислительных модуля, система КА "Канопус-В" содержит два построенных на процессоре архитектуры SPARC, с тактовой частотой 14 мегагерц, объемом оперативной памяти 4 мегабайта и содержащей блоки энергонезависимой памяти объемом 1 мегабайт[32]. Скромные по сравнению с ПК аппаратные ресурсы накладывают жесткие ограничения на выбор операционной системы и требуют реализации наиболее эффективных и одновременно наименее ресурсоемких алгоритмов бортового ПО. Сеть CAN содержит интерфейсные модули сопряжения (периферийные вычислители). Интерфейсные модели предназначаются для подключения по единому интерфейсу большой номенклатуры устройств. Данный интерфейсные модули могут иметь собственную логику управления присоединенными к нему устройствами, избавляя тем самым БВС от необходимости реализации специфических алгоритмов Использование периферийных управления конкретным вычислителей оборудованием. позволяет обеспечить распараллеливание и синхронизацию управляющих воздействий для реализации 15 выбранного цикла управления (дисциплины управления оконечным оборудованием). Так, например, можно распараллелить решение асинхронной задачи сбора телеметрической информации от датчиков, подключенных к периферийным вычислителям и их синхронную, централизованную передачу в бортовую вычислительную систему для использования в задачах анализа и дальнейшей транзитной передачи в НКУ. 1.1.4. Командная радиолиния Командная радиолиния космического аппарата (КРЛ) необходима для возможности взаимодействия борового и наземного комплексов управления. К ней предъявляются жесткие требования по обеспечению достоверности передаваемой информации и команд (сообщений). С этой целью используется помехоустойчивое кодирование. От реализации методов достоверности передачи данных зависит качество принимаемой на НКУ телеметрической информации. КРЛ должна обеспечить передачу достаточного для анализа и принятия решения по управлению объема телеметрической информации с космического аппарата, при этом обеспечивая прием и первичную проверку управляющих воздействий, с целью недопущения искажений передаваемых управляющих воздействий. Современные командные радиолинии построены на совместном использовании релейных\разовых команд (РК) и блоков командно-программной информации (КПИ). Релейные команды исполняются в блоке разовых команд (бортовом дешифраторе), выходы которого подключены напрямую (в обход бортовой вычислительной системы) к различному бортовому оборудованию. В качестве примера можно привести РК включения передатчика командной радиолинии, перезапуск бортовой вычислительной системы, включение системы обеспечения теплового режима и т.д. КПИ, напротив, могут быть приняты и обработаны только с использованием бортовой вычислительной системы. Количество и формат КПИ зависит от решаемых КА целевых задач, и от концепции 16 спроектированного бортового комплекса управления. В качестве примера информации, передаваемой при помощи различных типов КПИ можно привести: -установку текущего бортового времени -выдачу управляющих воздействий с абсолютной привязкой к временной шкале -задание начальных условий движения для баллистических расчетов -прием и запись модификаций ПО и т.д. В НКУ телеметрическая система КА отправляет определенным образом сформированные пакеты телеметрической информации. Сама по себе передача может осуществляться в режиме непосредственной передачи (НП) – передавая телеметрические данные воспроизведения(ВП) о ранее текущем состоянии записанной КА, информации, либо давая в режиме возможность анализировать состояние и поведение КА на длительном временном интервале. Телеметрическая информация является по сути единственным источником информации, позволяющем производить ретроспективную оценку состояния и поведения космического аппарата. Производимый на Земле анализ телеметрической информации позволяет сделать выводы о правильности работы алгоритмов управления КА, а также позволяет осуществлять подбор оптимальных коэффициентов, используемых в задачах управления КА. 1.2. Технологический цикл управления КА Космический аппарат является объектом управления с большим автономным сроком работы. От момента отделения от разгонного блока ракеты носителя, до вывода аппарата из строя система управления КА должна постоянно выполнять возложенные на нее функции по обеспечению, как жизнедеятельности КА, так и по обеспечению выполнения целевых задач. В зависимости от состояния КА может находиться в следующих режимах[18]: 17 -автономном. Основной режим работы космического аппарата. В данном режиме осуществляется исполнения заложенной ранее программы управления, запись и анализ текущей телеметрической информации; -сеансном. Режим, при котором космический аппарат взаимодействует с наземным комплексом управления. В сеансном режиме на Землю отправляется записанная ранее (или получаемая непосредственно в сеансе) телеметрия и принимаются команды управления; -испытательном. Данный режим реализуется для наземной отработки отдельных систем космического аппарата и их взаимодействия. После отделения космического аппарата происходит активация системы энергоснабжения, которая в свою очередь подает питание на бортовую вычислительную машину и системы бортового комплекса управления. БВС должна осуществить реализацию заложенных в нее алгоритмов обеспечения ориентации КА. После отделения от разгонного блока ракеты-носителя БКУ КА должен выполнить следующие действия: -Произвести самоконтроль; -Определить текущие угловые скорости вращения корпуса КА и произвести их гашение при помощи исполнительных органов системы ориентации; -Произвести ориентирование КА на Солнце, для обеспечения наилучшего притока электроэнергии от солнечных батарей; -Производить разгрузку накопленного кинетического момента двигателеймаховиков; -Произвести подрыв пиросредств солнечных батарей, и других приборов зачекованных при помощи данного технического средства; -Произвести инициализацию командной радиолинии; -Производить сбор, запись и анализ текущей телеметрической информации; -Произвести заложенные в программу полета действия; 18 -Активировать механизм распознавания, протоколирования и парирования нештатных ситуаций. Дальнейшие программы работы загружаются с Земли во время сеансов связи. БВС космического аппарата должна обладать достаточными ресурсами для хранения массивов полетных заданий, своевременно их отрабатывать и производить протоколирование своей работы. В течение срока активного существования на орбите системы космического аппарата могут выходить из строя и должны быть определены как неисправные автоматически, либо по командам с рекалибровки Земли. и Периодически перенастройки. различные Возможность системы КА обновления требуют различных конфигурационных параметров различного объема одним из неоспоримых преимуществ использования БЦВМ. При нахождении в процессе полета КА ошибок в алгоритмах его управления может быть произведена коррекция программного обеспечения с целью исправления логики его работы. Данный механизм используется очень редко, но позволяет производить существенное изменение функционирования КА. 1.3. ОСРВ их виды, механизмы, обзор рынка современных ОСРВ Современный рынок ОСРВ предлагает десятки наименований ОС общего и специального назначения. Само понятие системы реального времени определяет, что при достижении какого либо результата работы важен не только сам результат, сколько его своевременность. Поэтому в качестве основного требования к ОСРВ выступает детерминированность поведения системы при наихудших внешних условиях. Дополнительным определением системы реального времени может служить тот факт, что работа системы соизмерима со скоростью протекающих процессов, с которыми данная система должна осуществлять взаимодействие. Несомненно, что при конвейерной обработке 19 необходимо, чтобы рука манипулятора выполняла свои действия строго в обозначенное время, иначе процесс производства будет нарушен. Скорость протекания процессов, с которыми вынуждена взаимодействовать система реального времени могут различаться в разы. Так, скажем для управления зависанием вертолета на одном месте достаточно опрашивать датчики системы управления с частотой около пяти герц. При работе с реактором атомной электростанции необходимо получать актуальную информацию о процессах в реакторе и реагировать на них, для поддержания критического состояния реакции, значительно чаще. Современная терминология, принятая для ОСРВ различает системы «мягкого» и «жесткого» реального времени. В системах «жесткого» реального времени неспособность обеспечить реакцию на внешние события в течении заданного интервала времени может привести к отказам и полной невозможности выполнения поставленной задачи. К системам «мягкого» реального времени относят системы, не попадающие под определение «жесткие», другими словами обеспечивающие достижение результата при наихудших условиях работы, и к заданному сроку в среднем[9]. Системы «мягкого» реального времени могут не всегда успевать решать поставленную задачу, но это не приводит к отказу системы в целом. В системах реального времени необходимо введение некоторого директивного срока исполнения задачи. В системах «жесткого» реального времени задача должна быть во что бы то ни было исполнена к данному сроку. В системах же «мягкого» реального времени исполнение задачи в заданный временной интервал является желательным. Данный директивный срок используется планировщиком задач как для назначения приоритета задачи при ее запуске, так и при планировании работы процессов и называется дедлайном. Основные черты «жесткой» системы (ОСРВ): -гарантированное время реакции на внешние события (прерывания от оборудования); 20 -детерминированная подсистема диспетчеризации процессов (выполнение принципа невытеснения низкоприоритетными задачами высокоприоритетных задач); -жесткие требования к максимальному времени реакции на внешние события или реактивности (задержка вызова обработчика аппаратного прерывания должно составлять не более десятков микросекунд, а задержка на переключении контекстов задач не более сотен микросекунд). Мартин Тиммерман сформулировал следующие необходимые требования для ОСРВ[9]: -ОС должна быть многозадачной и допускать вытеснение; -ОС должна обладать механизмом приоритезации для планирования исполнения потоков; -ОС должна реализовывать предсказуемые механизмы синхронизации; -ОС должна обеспечивать механизм наследования приоритетов; -Поведение ОС должно быть предсказуемым (задержки обработки прерываний, задержки переключения задач, задержки драйверов и т.д.), это означает, что должно быть определена реактивность системы для всех сценариев рабочей нагрузки. В течение последних 25-30 лет структура операционных систем прошла эволюционный путь своего развития от монолитной к многослойной структуре ОС, и далее к архитектуре клиент-сервер. Приведем перечисление основных архитектур ОСРВ: -Монолитная архитектура. ОС определяется как набор модулей, взаимодействующих между собой внутри ядра системы и предоставляющих прикладному ПО входные интерфейсы для обращений к аппаратуре. Основной недостаток этого принципа построения ОС заключается в плохой предсказуемости её поведения, вызванной сложным взаимодействием модулей 21 между собой, а также крайне плохая масштабируемость и отсутствие возможности изменения поведения системы на лету. При монолитной структуре построения ОС состоит из набора модулей, и изменения в одном из модулей способны оказать влияние на систему в целом. Сложность эксплуатации системы растет прямо пропорционально количеству используемых модулей. Помимо этого, крайне сложно, мультипроцессорного а порой исполнения. невозможно Главным распределить достоинством ОС для монолитной архитектуры является ее высокая производительность[29] Рис. 1.2 - Монолитная архитектура ОСРВ -Уровневая (слоевая) архитектура. Прикладное ПО имеет возможность получить доступ к аппаратуре не только через ядро системы и её сервисы, но и напрямую. По сравнению с монолитной такая архитектура обеспечивает значительно большую степень предсказуемости реакций системы, а также позволяет осуществлять быстрый доступ прикладных приложений к аппаратуре. В многослойной структуре построения ОС изменения в пределах одного слоя влияют на соседние слои. 22 Рис.1.3 - слоевая архитектура ОСРВ -Архитектура «клиент-сервер». Основной принцип данной архитектуры заключается в вынесении сервисов ОС в виде серверов прикладного уровня и выполнении микроядром функций диспетчера сообщений между клиентскими прикладными программами и серверами — системными сервисами. Преимущества данной архитектуры: -Повышенная надёжность, благодаря выделению сервисов операционной системы в пользовательское пространство где проще производить его отладку и отслеживание ошибок; -Улучшенная масштабируемость, сервисы в которых отсутствует необходимость могут быть безболезненно исключены из конфигурации системы; -Повышенная отказоустойчивость, любой сервис исполняется в пользовательском пространстве в качестве приложения и может быть перезапущен без перезагрузки системы. За счет исполнения микроядра и сервисов ОС в разных адресных пространствах и на разных уровнях защиты процессора архитектура клиент23 сервер наименьшую, по сравнению с остальными архитектурами, производительность. Данное падение производительности связано с частыми переключениями из привилегированного в непривилегированный режим и обратно[29]. Рис.1.4 - клиент-серверная архитектура ОСРВ 1.4. Процессы, потоки, задачи Концепция многозадачности (концепция псевдопараллелизма) является одной из основополагающих для системы реального времени, исполняющейся в системе с единственным процессором, от приложений которой требуется способность обрабатывать многочисленные внешние события, происходящие асинхронно в случайные моменты времени. Понятие процесса, пришедшее из мира операционной системы UNIX, недостаточно эффективно реализуемо в многозадачной системе реального времени, поскольку процесс имеет достаточно объемный TCB – Task Control Block – управляющую структуру, включающую в себя все сведения о процессе. В ОСРВ определяется понятие новой сущности 24 потока, который реализуется как легковесный подпроцесс. Потоки выполняются в контексте одного процесса, благодаря чему межпоточное переключение происходит значительно быстрее, чем переключение порождающих процессов. При этом защита памяти между потоками отсутствует, что также увеличивает производительность из-за отсутствия проверок при обращениях к памяти. Потоки являются значительно более легковесными, за счет уменьшения регистрового контекста и содержимого управляющих блоков. Данные меры приводят к существенному уменьшению накладных расходов на сохранение и восстановление управляющих блоков переключаемых потоков. Таким образом, в системах реального времени процесс инкапсулирует в себе наименьшие единицы диспетчеризации - потоки. При анализе работы системы, построенной на базе ОСРВ, каждый процесс рассматривается как приложение. Систему стараются разрабатывать таким образом, чтобы минимизировать взаимодействие приложений имеющих различную природу – «жесткого» реального времени, «мягкого» реального времени, не реального времени. Рассматривая проблему дедлайнов, можно сказать, что главным для ОСРВ становится планирование задач, которое могло бы обеспечить предсказуемое поведение системы при любых обстоятельствах. Процесс с назначеннымы дедлайнами необходимо стартовать и выполнять так, чтобы он не пропустил ни одного своего дедлайна. Если выполнение данного требования не представляется возможным – запуск процесса должен быть отклонен. В практических реализациях ОСРВ применяются два подхода к планированию выполнения задач – статические алгоритмы планирования (RMS – Rate Monotonic Scheduling) и динамические алгоритмы планирования (EDF – Earliest Deadline First). RMS используется при формальном обосновании условий предсказуемости системы. Для реализации описываемой дисциплины чтобы ОСРВ имело реализацию планирования на основе приоритетов прерывающих обслуживание (preemptive priority scheduling). В теории RMS приоритет 25 назначается каждому процессу перед его стартом. Запускаемые процессы в свою очередь должны отвечать следующим требования: -процесс должен быть завершен за отведенное время; -процессы не имеют зависимости от хода выполнения и результатов исполнения друг друга; -каждому процессу требуется равные кванты процессорного времени на каждом интервале; -прерывание процесса должно происходит за ограниченное время. При планировании RMS предпочтение отдается задачам с самыми короткими периодами выполнения. После исполнения данных процессов производится исполнения оставшихся с использованием принципа исполнения первыми наиболее коротких процессов. В EDF приоритет процесса назначается динамически в зависимости от времени, оставшегося у процесса до окончания его исполнения. При больших загрузках системы EDF имеет преимущества перед RMS в части оптимальности исполнения. Во всех системах реального времени реализуется политика планирования, управляемая на основе дедлайнов. Обычно в ОСРВ используется планирование с приоритетами, которое, в свою очередь, основано на RMS. Приоритетное вытеснение является неотъемлемой составляющей ОСРВ, т.к. в системе реального времени должны существовать гарантии того, что событие с высоким приоритетом будет обработано перед событием с более низким приоритетом. Данные требования и ограничения накладываемые на систему приводят к тому, что в ОСРВ должен быть реализован не только механизм планирования на основе приоритетов, прерывающих обслуживание, но и соответствующий механизм управления прерываниями. Кроме того, ОСРВ должна иметь возможность запрета 26 прерываний, в ситуациях, когда имеется необходимость исполнения критического код, исполнение которого не должно прерываться. Длительность обработки прерываний в ОСРВ должна быть сведена к минимуму. ОСРВ должна обладать развитой системой приоритетов. Во-первых, потому, что сама система в целом рассматривается приложений, подразделяющихся как набор серверных на потоки, и ряд наивысших уровней приоритетов должен быть выделен для системных процессов и потоков. Вовторых, в сложных приложениях необходимо все потоки реального времени помещать на разные приоритетные уровни, а потоки не реального времени помещать на один уровень (приоритет которого ниже, чем приоритет любого потока реального времени). При этом потоки не реального времени можно обрабатывать в режиме циклического планирования, при котором каждому процессу предоставляется квант времени процессора, а когда квант заканчивается, его контекст сохраняется, и процесс ставится в конец очереди. Многие ОСРВ используют циклическую диспетчеризацию для планирования задач на одном уровне. Приоритетный уровень 0 обычно используется для холостого режима и показывает суммарную степень загруженности системы. Для успешного планирования на основе приоритетов ОСРВ должна в обязательном порядке иметь способы разрешения двух следующих проблем: -обеспечение выполнения процесса с наивысшим приоритетом в самую первую очередь; -недопущение инверсии приоритетов, при которой задачи с высокими приоритетами вынуждены ожидать ресурсы, захваченные низкоприоритетными задачами. Для борьбы с инверсией приоритетов в ОСРВ применяется механизм наследования приоритетов, однако при использовании данного механизма 27 требуется отказ от планирования на основе RMS, поскольку приоритеты задач становятся динамическими. В общем виде организацию процесса управления потоками и задачами можно представить на схеме: Рис 1.5 Граф многозадачности Как видно из схемы 1.5 операционная система оперирует задачами, выставляя их в две различные очереди. Очередь на исполнение – очередь задач с равными, либо отличающимися приоритетами, готовых к исполнению. Очередь заблокированных задач – очередь, содержащая задачи заблокированные ожиданием ресурса, освобождением семафора, выполняющие операции задержки. Перед своим последующим исполнением данные задачи попадают в очередь на исполнение, где обслуживаются наряду с остальными. 1.5. Память Задержка на переключение контекста потока находится в прямой зависимости зависит от конфигурации памяти, т.е. от модели защиты памяти. Рассмотрим четыре наиболее распространенных в ОСРВ модели защиты памяти: 28 -Модель без защиты – системное и пользовательское адресные пространства не разделены и не защищены друг от друга, используется всего два сегмента памяти: сегмент кода и сегмент данных, при этом от системы не требуется никакого специального управления памятью, также не требуется и MMU (memory management unit – устройство управления памятью - специальное аппаратное устройство для поддержки управления виртуальной памятью); -Модель защиты система/пользователь – системное адресное пространство защищено от адресного пространства пользователя, при этом системные и пользовательские процессы выполняются в общем виртуальном адресном пространстве, для поддержки данной модели требуется MMU. Защита памяти основана на использовании механизма защиты отдельных страниц. Так различают всего два вида страниц – пользовательские и системные. Пользовательские приложения, выполняющиеся в одном адресном пространстве, не защищены друг от друга. Для реализации данной модели требуется выделение четырех сегментов в памяти – два сегмента для работы на уровне ядра ОС (сегменты кода и данных) и два сегмента для работы на пользовательском уровне. Механизм страничной защиты не добавляет накладных расходов, так как защита страницы проверяется одновременно с преобразованием адреса, которое выполняет MMU, при этом от ОС не требуется дополнительной функциональности по управлению памятью; -Модель защиты пользователь/пользователь – в модели система/пользователь дополнительно вводится защита памяти пользовательских процессов, для реализации которой требуется MMU. Сама защита памяти также реализована на базе механизма страничной защиты. Со стороны процесса все страницы памяти кроме его собственных выглядят как привилегированные и не допускают доступа. Таким образом, выполняющийся поток не может обратиться за пределы своего адресного пространства и нарушить тем самым работу других потоков. От ОС требуется обновление флага привилегий для 29 конкретной страницы в таблице страниц при переключении процесса. Как и в предыдущей модели необходимо использование четырех сегментов памяти; -Модель защиты виртуальной памяти – каждый процесс выполняется в своей собственной виртуальной памяти для реализации которой требуется MMU. Каждый процесс имеет свои собственные сегменты и, следовательно, свою таблицу описателей. ОС несет ответственность за поддержку таблиц описателей. Адресуемое пространство может превышать размеры физической памяти, если используется страничная организация памяти совместно с подкачкой. Однако в системах реального времени подкачка с диска не применяется из-за ее недетерминированности. Одним из основополагающих требований к организации работы с памятью в системе реального времени заключается в том, что время доступа к ней должно быть детерминировано. Прямым следствием из данного требования становится запрет на использование техники выгрузки страниц и загрузки страниц по запросу с внешних устройств для процессов требующих реального времени. Поэтому системы, реализующие механизм виртуальной памяти, должны также блокировать процессы реального времени в оперативной памяти, не допуская подкачки. Итак, подкачка недопустима в ОСРВ, потому что не является предсказуемой по времени выполнения. Если системой поддерживается страничная организация памяти, соответствующее отображение страниц в физические адреса необходимо выполнить как часть контекста процесса. В противном случае появляется непредсказуемость, неприемлемая для ОСРВ. Для процессов, не являющихся процессами "жесткого" реального времени, возможно использование механизма динамического распределения памяти, однако при этом ОСРВ должна поддерживать обработку таймаута на запрос памяти, т.е. ограничение на предсказуемое время ожидания. В обычных ОС при использовании механизма сегментации памяти для борьбы с фрагментацией применяется процедура уплотнения после сборки мусора. Однако такой подход 30 неприменим в среде реального времени, так как во время уплотнения перемещаемые задачи не могут выполняться, что ведет к потере непредсказуемости поведения системы. В этом состоит основная проблема применимости объектно-ориентированного подхода к системам реального времени. До тех пор, пока проблема уплотнения не будет решена, C++ и JAVA будут оставаться не самым лучшим выбором для систем жесткого реального времени. В системах жесткого реального времени обычно применяется статическое распределение памяти. В системах мягкого реального времени возможно динамическое распределение памяти, без виртуальной памяти и без уплотнения. 1.6. Прерывания При описании управления прерываниями обычно различают две процедуры, а именно: -программа обработки прерывания (ISR – interrupt servicing routine) – программа низкого уровня в ядре с ограниченными системными вызовами; -поток обработки прерывания (IST – interrupt servicing thread) – поток уровня приложения, который управляет прерыванием, с доступом ко всем системным вызовам. Обычно ISR реализуются производителем аппаратуры, а драйверы устройств выполняют управление прерываниями с помощью IST. Потоки обработки прерываний действуют как любые другие потоки и используют ту же самую систему приоритетов. Это означает, что проектировщик системы может назначить IST более низкий приоритет, чем приоритет потока приложения. Одной из основных проблем разработки ОСРВ является поддержка асинхронного доступа к внутренним структурам данных операционной системы из обработчиков прерываний. Она не должна быть доступна по той причине, что 31 при изменении этой структуры данных исполнение обработчика прерывания также может быть прерванное еще одним прерыванием. Частично измененная в первом обработчике структура данных несет в себе некорректное состояние и интерпретация этих данных во втором обработчике может привести к краху системы. Все ОСРВ должны предотвращать возможность модификации одной и той же структуры данных из обработчиков прерываний. Существует, по меньшей мере, два подхода к реализации работы с прерываниями в ОСРВ. Наиболее простой и популярный механизм носит название «Унифицированная архитектура прерываний». Его суть заключается во временном блокировании остальных прерываний при начале обработки вновь поступившего прерывания. Это надежно предотвращает несогласованный доступ к критическим структурам данных из обработчиков прерываний. Рис 1.6 - Схема унифицированной архитектуры прерываний Второй, менее популярный способ, не маскировать прерывания, а обеспечить недопущение асинхронного доступа к критически важным структурам данных из обработчика прерывания. Работа с критическими структурами данных делегируется второму обработчику, который будет в дальнейшем исполнен наряду с пользовательскими потоками, с использованием планировщика задач. 32 1.7. Часы и таймеры В любой ОСРВ используются различные службы ведения и выдачи времени. Операционная система отслеживает текущее время, в определенное время запускает задачи и потоки и приостанавливает их исполнение на определенные интервалы. Службы времени ОСРВ используют высокоточные аппаратные часы для своей работы. Для отсчета временных интервалов на основе часов реального времени создаются таймеры. Для каждого процесса и потока определяются объекты следящие за использованием процессорного времени. На базе данных объектов создаются таймеры, которые измеряют перерасход времени процессом или потоком, позволяя динамически выявлять программные ошибки или ошибки вычисления максимально возможного времени выполнения, а также профилировать приложение. В высоконадежных, критичных ко времени системах важно выявление ситуаций, при которых задача превышает максимально возможное время своего выполнения, так как при этом работа системы может выйти за рамки допустимого времени отклика. Таймеры контролирующие время исполнения процессов перерасхода времени предотвращению или и такого потоков позволяют активизировать поведения. выявлять возникновение соответствующие Большинство ОСРВ действия по оперируют относительным временем. Что-то происходит “до” и “после” некоторого другого события. В системе, полностью управляемой событиями, необходим часовой механизм, так как там нет квантования времени (time slicing). Однако, если нужны временные метки для некоторых событий или необходим системный вызов типа “ждать одну секунду”, тогда нужен тактовый генератор и/или таймер. Синхронизация в ОСРВ осуществляется с помощью механизма блокирования (или ожидания) до наступления некоторого события. Абсолютное время не применяется. Реализации в ОСРВ других концептуальных абстракций подобны их реализациям в традиционных ОС. 33 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. 34 Распространенным также является стандарт OSEK/VDX, который первоначально развивался для систем, используемых в автомобильной индустрии. 1.8.1. POSIX Стандарт POSIX был разработан в качестве стандартного интерфейса сервисов операционных систем. Основным назначением стандарта является предоставление возможности разработки и создания переносимых приложений. Позднее данный стандарт был существенно дополнен специфическими для режима реального времени особенностями. Спецификации стандарта POSIX определяют стандартный механизм взаимодействия прикладного ПО и операционной системы. Исторически при своем создании и дальнейшем развитии, стандарт POSIX был тесно связан со стандартами Unix-подобных операционных систем и непосредственно с ОС UNIX. Несмотря на этот факт разработчики многих ОС, включая ОСРВ, ставят перед собой целью реализовать в своих разработках соответствие стандарту POSIX. Соответствие стандарту POSIX для ОС и аппаратной платформы должно быть сертифицировано при помощи исполнения на них набора специфических тестов. В случае если ОС не является Unix-подобной, выдержать соответствие тестовым проверкам становится чрезвычайно сложной задачей. Наборы тестовых инструкций реализованы только для POSIX 1003.1a. По причине того, что стандарт POSIX представляется совокупностью факультативных интерфейсов, реализация всего множества которых не является обязательной, разработчики ОС предпочитают реализовать только часть стандартного интерфейса. При этом появляется понятие POSIXкомплиантности системы - частичное или полное соответствии системы стандарту. Несмотря на то, что стандарт POSIX в своей основе содержит многие основополагающие принципы операционной системы Unix, он затрагивает основополагающие абстракции которые в большинстве относятся ко всем 35 операционным системам, а расширения стандарта в части реального времени могут быть применимы к подавляющему большинству ОСРВ. В настоящее времени стандарт POSIX рассматривается как раздел взаимодополняющих стандартов: IEEE Std 1003.n (где n – это индекс). Стандарт 1003.1a (OS Definition) перечисляет базовые интерфейсы ОС – поддержку работы с единственным процессом, поддержку работы с множеством процессов, управление системой заданий, сигналов, группами пользователей, файловыми системами, атрибутами файлов, управление файловыми устройствами, блокировкой файлов, устройствами ввода/вывода, специализированными устройствами, системными базами данных, именованными каналами и очередями FIFO, а также поддержку языка программирования Си. Стандарт 1003.1b (Realtime Extensions) содержит расширения стандарта относящиеся к поддержке реального времени. К ним относятся: -сигналы реального времени; -планирование выполнения (с учетом приоритетов, циклическое планирование); -таймеры; -синхронный и асинхронный ввод/вывод; -ввод/вывод с приоритетами; -синхронизация файлов; -блокировка памяти, разделяемая память, передача сообщений, семафоры. Для соответствия стандарту POSIX, ОС должна реализовать не менее 32 уровней приоритетов для процессов. POSIX определяет три основных политики диспетчеризации и планирования исполнения процессов: -SCHED_FIFO – процессы обрабатываются порядке поступления в очередь исполнения и выполняются до полного завершения; 36 -SCHED_RR – round robin – циклическое планирование -данная дисциплина выделяет каждому текущему процессу, готовому для исполнения, квант времени по окончании которого процесс принудительно прерывается и помещается в конец очереди исполнения; -SCHED_OTHER SCHED_OTHER, – планирование является процессов, использующее реализационно-зависимым и не является переносимым между платформами. Стандарт 1003.1c (Threads) относится к механизмам реализации мультипрограммирования в пределах одного процесса – реализация механизма потоков, диспетчеризация потоков на основе приоритетов, взаимоисключающие семафоры - мьютексы (объекты синхронизации при межпоточном взаимодействии, при захвате себя одним потоком не дают возможности захвата другим потокам), наследование приоритетов для объектов синхронизации, переменные состояния. Стандарт 1003.1d определяет механизмы дополнительных расширений реального времени – семантика порождения новых процессов, спорадическое серверное планирование, мониторинг процессов и потоков времени исполнения, таймауты функций блокировки, управление устройствами и прерываниями. Стандарт 1003.21 относится к распределенным системам реального времени и определяет функции поддержки распределенного взаимодействия, организации буферизации данных, перемещение управляющих блоков, синхронных и асинхронных операций, ограниченной блокировки, приоритезации сообщений, меток сообщений, и реализаций протоколов. Стандарт 1003.2h относится к сервисам, отвечающих за работоспособность системы. 37 1.8.2. DO-178B Стандарт DO-178B (Software Considerations in Airborne Systems and Equipment Certification), был разработан рабочей группой Радиотехнической комиссии по аэронавтике (RTCA, Radio Technical Commission for Aeronautics) для разработки ПО бортовых авиационных систем и утвержден в своей референсной версии в январе 1992 года. В январе 2012 была принята DO-178C, причиной этому послужила необходимость пересмотра довольно старого на текущий момент DO178B в соответствии с текущим развитием информационных технологий и программного обеспечения. Стандартом предусмотрено пять уровней описания степени серьезности отказа, и для каждого из данных уровней определен набор требований к программному обеспечению, которые должны гарантировать работоспособность всей системы в целом при возникновении отказов данного уровня отказа. Данный стандарт основывается на методе оценки опасности, которую может вызвать неправильная работы системы в первую очередь для пассажиров и экипажа воздушного судна, и определяет следующие уровни сертификации: - А (катастрофический) данный отказ может привести к множественным человеческим жертвам, и потере воздушного судна. Дальнейший полет и приземление при данном отказе невозможны; - В (опасный) – отказ производительность и имеет большое негативное воздействие на работоспособность системы, что может привести к человеческим жертвам; - С (существенный) отказ существенно уменьшает запас надежности и приводит к увеличению роли человека в управлении, что может привести к жертвам или травмам; - D (несущественный) отказ не оказывает существенного влияния на безопасность системы, но может вызвать необходимость скорейшее изменение 38 режима ее эксплуатации. Применительно к самолету это может обозначать необходимость смены маршрута полета для аварийной посадки; - Е (не влияющий) отказ никак не влияет на безопасность работы системы. До тех пор пока все жесткие требования этого стандарта не будут выполнены, вычислительные системы, влияющие на безопасность, не будут допущены для управления летательным аппаратом. Дополнительно DO-178B рассматривает возможные пути повышения безопасности системных решений в области программного обеспечения. К ним относятся, в частности, выделение программных функций в независимые процессы, параллельная разработка нескольких вариантов реализации одной и той же функциональности. 1.8.3. ARINC-653 Стандарт ARINC-653 (Avionics Application Software Standard Interface) разработаный компанией ARINC в 1997 г. Данный стандарт определяет универсальный программный интерфейс APEX (Application/Executive) между ОС бортового авиационного БЦВМ и прикладным ПО. Требования к интерфейсу между прикладным ПО и сервисами операционной системы определяются таким образом, чтобы позволять прикладному ПО производить контроль диспетчеризацию, связь и текущее состояние внутренних обрабатываемых элементов. ARINC 653 регламентирует временное и пространственное разделение ресурсов авиационной ЭВМ в соответствии с принципами интегрированной модульной авионики (Integrated Modular Avionics) и определяет программный интерфейс, который должен использоваться в прикладном ПО для доступа к ресурсам БЦВМ. 39 ARINC 653 входит в серию 600 стандартов ARINC. В данной серии определены стандарты на цифровую авионику. В 2006 г. Была принята новая редакция этого стандарта. ARINC-653 в качестве одного из основных требований к ОСРВ в авиационной промышленности вводит понятие изолированных (partitioning) виртуальных машин. В 2007 году было выпущено очередное дополнение стандарта. Оно касается организации холодного и горячего старта модулей авионики, стандартов обработки ошибок приложениями. В настоящее время стандарт расширен еще четырьмя дополнениями: базовые сервисы, дополнительные сервисы, порядок сертификации, подмножества сервисов. 1.9. Обзор современных ОСРВ Рынок современных ОСРВ предоставляет на выбор десятки наименований операционных систем. Не каждая из них может быть использована для реализации процесса управления космическим аппаратам. Ряд систем реального времени имеют поддержку лишь одной двух аппаратных платформ и в первую очередь разрабатывались для программирования микроконтроллеров. Часть ОС не соответствуют стандартам. Со времени выделения ОСРВ в отдельную ветвь появились явные лидеры индустрии. Эти операционные системы реализуют все концепции, присущие данному виду систем. Напротив существуют системы, не являющиеся изначально предназначенными для использования в задачах с требованиями к жесткому реальному времени исполнения, но после доработок успешно отвечающие этим требованиям. В данной работе будет рассмотрено 4 операционных системы: -VxWorks; -QNX; 40 -RTEMS; -RT-Preempt Linux. 1.9.1. VxWorks VxWorks является операционной системой реального времени, рассчитанной на применение в качестве встраиваемой системы. Первая версия вышла в 1987 году и с тех пор система продолжает совершенствоваться. Особенности системы: -Поддержка вытесняющей многозадачности и циклической многозадачности; -Быстрая обработка прерываний; -Приложения пользовательского уровня могут выполняться в изолированной от других приложений среде при помощи механизма защиты встроенного в ядро; -Поддержка симметричного и ассиметричного мультипроцессирования ; -Бинарные, счетные и взаимоисключающие семафоры с поддержкой наследования приоритетов; -Поддержка частных и глобальных очередей сообщений; -POSIX совместимая система; -Поддержка файловых систем HRFS, FAT, NFS; -Поддержка стека протоколов TCP/IP; -Неограниченное количество запускаемых задач ; -256 приоритетов для задач; -Детерменированное время переключение контекста ; -Поддержка большого количества оборудования. Операционная система VxWorks имеет архитектуру клиент-сервер, и построена в соответствии с технологией микроядра, т.е. на самом нижнем 41 непрерываемом уровне ядра (WIND Microkernel) обрабатываются только планирование задач и управление их взаимодействием/синхронизацией. Вся остальная функциональность операционного ядра – управление памятью, вводом/выводом и пр. – выполняется на более высоком уровне и реализуется через процессы. Это обеспечивает быстродействие и детерминированность ядра, а также масштабируемость системы. Для того чтобы реализовать быструю обработку прерываний – обработчики прерываний выполняются в специальном контексте, вне контекста потоков. VxWorks может быть скомпонована как для небольших встраиваемых систем с жесткими ограничениями для памяти, так и для сложных систем с развитой функциональностью. Более того, отдельные модули сами являются масштабируемыми. Конкретные функции можно убрать при сборке, а специфические ядерные объекты синхронизации можно опустить, если приложение в них не нуждается. Хотя система VxWorks является конфигурируемой, т.е. отдельные модули можно загружать статически или динамически, нельзя сказать, что она использует подход, основанный на компонентах. Все модули построены над базовым ядром и спроектированы таким образом, что не могут использоваться в других средах. В настоящее время VxWorks перенесен на множество архитектур и в их числе: -x86; -MIPS; -PowerPC ; -Freescale ColdFire ; -Intel i960 ; -SPARC; -Fujitsu FR-V; -SH-4. 42 VxWorks поддерживает два вида мультипроцессинга: слабосвязанный – через распределенные очереди сообщений и сильносвязанный – через объекты в разделяемой памяти. Слабосвязанный мультипроцессинг через распределенные очереди сообщений реализован в библиотеке VxFusion, которая является отдельным продуктом. VxFusion применяется для обмена между процессорами, не имеющими общей памяти (например, между узлами сети). Сильносвязанный мультипроцессинг через объекты в разделяемой памяти реализован в библиотеке VxMP, которая также является отдельным продуктом. VxMP применяется для обмена между процессорами, имеющими общую область памяти (например, находящимися на одной шине). Все аппаратно-зависимые части VxWorks вынесены в отдельные модули для того, чтобы разработчик встраиваемой компьютерной системы мог сам портировать VxWorks на свой нестандартный целевой компьютер. Этот комплект конфигурационных и инициализационных модулей называется BSP (Board Support Package) и поставляется для стандартных компьютеров (VME-процессор, PC или SparcStation) в исходных текстах. Разработчик нестандартного компьютера может взять за образец BSP наиболее близкого по архитектуре стандартного компьютера и портировать VxWorks на свой компьютер путем разработки собственного BSP с помощью BSP Developer's Kit. Среда разработки и набор компиляторов позволяют вести кросс-разработку ПО для VxWorks на языках Си, C++, Ada, Java. 1.9.2. RTEMS Операционная система RTEMS представляет собой полнофункциональную ОСРВ с открытым исходным кодом. В первоначальном своем варианте система разрабатывалась по заказу министерства обороты США[2] для использования в крылатых ракетах. В настоящий момент разработкой системы руководит 43 компания OAR, а принять участие в разработке может любой желающий, при этом система достаточно стабильна, несмотря на свое постоянно развитие. Система поддерживает ряд стандартов интерфейсов программирования приложений (API) и стандартов интерфейсов операционных систем таких как POSIX и BSD сокеты. Области применения данной ОС достаточно широки – от космической техники до медицинского оборудования. Одним из самых известных примеров применения RTEMS является автоматическая межпланетная станция для исследования Марса на которой RTEMS используется в качестве ОС одной из подсистем. Благодаря использованию компилятора GCC и продуманной архитектуры построения проекта ОС RTEMS может быть собран практически для всех архитектур, которые поддерживает GCC[3]. В их состав входят: -ARM; -PowerPC; -Intel x86; -Blackfin; -MIPS; -Microblaze; -SPARC; -Intel i960. Средства разработки и кросс-компиляции также доступны для широкого круга ОС, включая GNU/Linux, MS-Windows, FreeBSD, Solaris. возможности RTEMS: -Поддержка POSIX 1003.1b API включая потоки; -RTEID/ORKID API; -Поддержка стека протоколов TCP/IP: -UDP, TCP; -ICMP, DHCP, RARP; 44 Основные -Поддержка целого ряда файловых систем: -Корневая виртуальная ФС размещаемая в ОЗУ In-Memory Filesystem (IMFS); -FAT; -NFS; -RFS (RTEMS file system) родная файловая система RTEMS. -Поддержка многозадачности; -Выполнение в гомогенных и гетерогенных мультипроцессорных системах; -Событийно-управляемая, приоритетная, вытесняющая многозадачность; -Поддержка rate monotonic scheduling (RMS); -Наследование приоритетов; -быстрая обработка прерываний; -динамическое выделение памяти; -динамическая загрузка и связывание модулей; -широкие возможности для конфигурации системы; -Очереди сообщений; -Механизм сигналов; -Возможность встраивания интерпретатора языка Python. 1.9.3. QNX Одна из самых известных операционных систем основанная на технологии микроядра. Первый релиз системы состоялся в 1982 году. В настоящее время считается хорошо проработанной системой содержащей минимальное количество ошибок. QNX идеально подходит для встраиваемых приложений реального времени. Она может быть масштабирована до самых компактных конфигураций и способна работать в многозадачном режиме, управлять потоками, осуществлять планирование процессов по приоритетам и выполнять быстрое переключение 45 контекста. Более того операционная система предоставляет все эти возможности посредством программного интерфейса, основанного на стандартах POSIX[4]. Таким образом, компактность системы достигается не в ущерб стандартам. Кроме того, QNX обладает достаточной гибкостью в настройке. Разработчик может легко изменять ее конфигурацию в соответствии с требованиями создаваемых приложений. При разработке можно использовать только те ресурсы, которые необходимы для конкретной задачи, изменяя систему в диапазоне от минимальной конфигурации микроядра с несколькими базовыми модулями до полнофункциональной сетевой системы, предназначенной для обслуживания сотен пользователей. Принцип модульности ОСРВ QNX достигается в основном за счет двух фундаментальных особенностей: микроядерной архитектуры, и глобального межзадачного обмена сообщениями. ОС QNX строится на основе компактного микроядра, способного управлять группой взаимодействующих процессов. Микроядро реализует следующие базовые функции: -управление потоками посредством POSIX-примитивов для создания потоков; -управление сигналами; -обмен сообщениям, с помощью которого микроядро выполняет трассировку вех сообщений, пересылаемых между всеми потоками в системе; -синхронизацию посредством примитивов синхронизации потоков; -планирование; -управление таймерами; -управление процессами. В отличие от потоков, микроядро никогда не планируется на выполнение. Процессор выполняет код в микроядре только в случае явного вызова ядра, при возникновении исключения или в результате аппаратного прерывания. 46 Все службы ОС, за исключением тех, которые выполняются обязательным модулем микроядра, обрабатываются посредством стандартных процессов. К их числу могут относится: -администраторы файловых систем; -администраторы устройств символьного ввода-вывода; -графический сервер; -сетевой администратор; -стек протоколов TCP/IP. Системные процессы по сути ничем не отличаются от пользовательских. Они используют те же самые унифицированные службы программного интерфейса ядра. Которые доступны для любого пользовательского процесса, имеющего соответствующие привилегии. Поскольку большинство служб ОС выполняются стандартными системными процессами, конфигурация ОС может быть легко дополнена новыми компонентами, для чего достаточно написать соответствующие программы, предназначенные для выполнения новых служб[5]. 1.9.4. RT-Preempt-Linux Популярная UNIX-подобная операционная система с открытым исходным кодом. Система построена, в отличие от большинства современных ОСРВ, на основе монолитного ядра с возможностью загрузки и выгрузки отдельных модулей. Стандартное ядро Linux полностью отвечает только требованиям мягкого реального времени: оно предоставляет основные операции POSIX управления временем исполнения для пользовательского уровня, но отнюдь не гарантирует выполнения за жестко фиксированное время. С патчем к ядру RT47 Preempt и таймером с поддержкой высокой точности, ядро получило возможность работать в режиме жесткого реального времени. RT-Preempt способен работать на x86, x86_64, ARM, MIPS, и PowerPC архитектурах. Список поддерживаемых платформ постоянно пополняется[24]. Патч RT-Preempt вызвал большой интерес во всей индустрии ОСРВ. Его понятный и простой дизайн и направленность на интеграцию в основную ветку ядра делает его интересным для приложений требующих жесткого реального времени от аудиообработки до задач управления промышленными процессами. Патч RT-Preempt превращает ядро Linux в полностью вытесняемое ядро при помощи[23]: -Создания внутриядерных блокировок (используя спинлоки) вытесняемых через переопределенные мьютексы реального времени; -Критические секции защищенные spinlock_t и rwlock_t вытесняемы. Создание невытесняемых секций в ядре также доступно с использованием aw_spinlock_t -Реализация механизма наследования приоритетов для внутриядерных блокировок и семафоров; -Преобразование обработчиков прерываний в вытесняемые потоки ядра: патч RT-Preempt выполняет исполнение обработчиков прерываний в контексте потока ядра, и представляет их при помощи task_struct как и большинство процессов пользовательского уровня; -Преобразования старого API таймера в отдельные подсистемы для таймеров высокой точности которые также используются для POSIX таймеров пользовательского пространства. Плюсами RT-Preemp является то, что в общем случае нет даже необходимости перекомпилировать приложения для исполнения их в режиме реального времени, также не требуется запуск от имени суперпользователя. Тем не менее, для специфических возможностей по использованию реального времени 48 все же требуется перекомпиляция приложений, и написание специальных приложений для работы в реальном времени. В целом использование RT_Preempt Linux позволяет существенно ускорить разработку за счет широкого применения уже существующих библиотек, инструментальных и утилитарных средств. Отладка ПО может быть выполнена на IBM PC совместимых компьютерах с последующей перекомпиляцией под целевую платформу. Минусами использования данной системы является более высокие системные требования для запуска. В основном это относиться к оперативной памяти и дисковому пространству. Поэтому RT-Preempt-Linux применяется в основном на рабочих станциях, в которых необходимо исполнение задач в реальном времени, без перехода на другую ОС. 1.10. Инструментальные средства для программирования под ОСРВ. Современная ОСРВ представляет собой сложную и гибкую в настройке систему. Полнофункциональная разработка для подобной системы возможна только с использованием специализированных инструментальных средств. Большинство разработчиков ОСРВ выпускают специализированные среды разработки и отладки ПО. По такому пути в частности шли WindRiver и National Instruments. В настоящее время ряд компаний отказывается от разработки самостоятельных комплексов, предпочитая расширять возможности IDE общего назначения. Одним из ярких примеров такой среды может служить IDE Eclipse, на основе которого созданы следующие среды разработки: -среда разработки WindRiver Workbench – используемая для разработки под VxWorks[12]; -QNX Momentics Tool Suite; 49 -плагин Eclipse для разработки под RTEMS[2]. Также, как и среда для разработки ПО для операционных систем общего пользования IDE для разработки под ОСРВ должна обеспечивать: -редактирование исходного кода; -возможность использования системы контроля версий; -статистический анализ кода; -гибкая настраиваемость; -поддержка плагинов ; -настройка специфических параметров системы. Использование обеспечения для специализированных операционных систем сред разработки реального программного времени позволяют существенно ускорить процесс разработки ПО, производить анализ и выявлять ошибки в коде, реализовывать механизмы рефакторинга для переноса кода из других проектов или других версий операционных систем. При разработке проектов современного ПО, состоящих из сотен и тысяч файлов исходного кода, работа без средств автоматизации разработки практически неосуществима. 1.11. Сравнение выбранных операционных систем Таблица 1.1 - Сравнение выбранных операционных систем Поддерживае мые платформы VxWorks x86, PowerPC, ARM, MIPS, 68K, CPU 32, QNX X86, ARM, XScale, PowerPC, MIPS 50 RTEMS X86,Arm,AVR,i9 60,MC68,Coldfir e,PowerPC,SPAR C RT-LINUX X86, ARM,Xscal e Архитектура системы Размер ядра ColdFire, MCORE, Pentium, i960, SH, SPARC, NEC V8xx, M32 R/D, RAD6000, ST 20, TriCore Клиентсерверная. Микроядро. 16 кб (версия 5.4) 150 кб (версия 6) 256 Число уровней приоритетов Политики FIFO с планирования приоритета ми, циклическо е, адаптивное, спорадичес кое планирован ие Максимально Неограниче е число задач но Клиентсерверная. Микроядро. От 7 кб Иерархическая многослойная с микроядром 150 кб Монолитна я 256 256 40 FIFO с приоритетами, циклическое, адаптивное, спорадическое планирование FIFO с приоритетами, циклическое, адаптивное, спорадическое планирование, RMS Неограничено Неограничено FIFO с приоритета ми, циклическо е, адаптивное, спорадичес кое планирован ие Неограниче но 51 От 300 кб 2. Разработка бортового программного обеспечения Системы обработки данных реального времени в космической отрасли характеризуются большим разнообразием и сложностью взаимосвязей составляющих их элементов, необходимостью обработки потока заявок на вычислительные ресурсы, поступающих в определенные и случайные моменты времени и требующих выполнения жестких ограничений на время обслуживания. Кроме того системы обработки данных данного класса независимо от их функционального назначения характеризуются рядом особенностей, к числу которых относится[1]: -Взаимодействие с объектом управления в интерактивном режиме; -относительно слабая предсказуемость моментов поступления заявок на обслуживание и времени их обслуживания; -использование текущего времени в качестве основного задающего параметра организации вычислительного процесса; -Работа с прерываниями, количество и время появления которых является случайным; -использование режимов мультипрограммирования и мультиобработки, непосредственное управление ЭВМ процессами ввода-вывода информации со специализированных устройств сопряжения с объектом -работа в режиме теледоступа; -необходимость динамического изменения правил организации очередей заявок на обслуживание в системе в зависимости от реальной ситуации и приоритетов заявок. Программное обеспечение бортовой вычислительной системы должно строится по модульному принципу. Модульный принцип проектирования ПО связан с процессом синтеза системы как совокупности слабосвязанных 52 компонент, допускающих их относительно независимую разработку и использование. Проблемы декомпозиции системы на подсистемы, задачи на подзадачи, программного обеспечения на отдельные программы и подпрограммы, возникают на различных этапах анализа и синтеза систем управления. Использование принципа модульности при проектировании программного обеспечения космического аппарата позволяет свести проектирование к оптимальному синтезу функционально-независимых совместно выполняющих заданные функции отдельных модулей, системы с требуемой эффективностью, и значительно сокращает затраты на разработку, внедрение и модификацию систем. При проектировании модульных систем должны быть обеспечены такие основные их свойства, как: функциональность, связность, алгоритмичность, последовательность, маскировка. Любые параметры, влияющие на управление и управляемость КА должны иметь возможность конфигурации. Единожды жестко установленные на Земле значения параметров впоследствии эксплуатации могут становиться неприемлемыми и требовать коррекции. Наиболее оптимальным вариантом передачи конфигурационных параметров на борт могут служить специально определенные виды командно-программной информации. При проектировании ПО бортовой вычислительной системы КА одним из ключевых моментов является выбор операционной системы реального времени. Главной задачей ОСРВ является обеспечение возможности своевременной реакции бортовой вычислительной системы на происходящие события, в том числе на одновременно происходящие события. При времени проектировании вначале аппаратно-программного оценивают критерии, комплекса предъявляемые к реального объекту, и классифицируют события на этом объекте. Выделяют события, реакция на которые в заранее запланированное время строго необходима. С каждым событием связывается критическое время отклика на него. Затем прогнозируются 53 худшие из прогнозируемых ситуаций на объекте, описываются требования к поведению системы в этих ситуациях. Операционная система реального времени, используемая на КА должна отвечать следующим требованиям: -Скорость реакции системы должна быть соизмерима со скоростью протекающих процессов; -Отказоустойчивость. Работа системы должны быть непрерывной в течение всего срока активного существования КА; -успешные случаи применения подобной ОС в реальном полете, либо на имитаторе замкнутого контура. Данный пункт очень важен в плане определения зрелости системы и возможности ее использования в качестве основы построения системы управления КА; -Возможность создания бездисковой конфигурации; -Наличие необходимых драйверов устройств; -Малый размер системы; -Поддержка необходимых механизмов диспетчеризации и назначения приоритетов; -Развитые средства межзадачного взаимодействия; -Средства реализации служб времени. Таким образом выбор операционной системы для конкретного проекта предстает непростой задачей требующей взвешенных решений. Рассмотрим конкретный проект: Космический аппарат «Канопус-В» спроектирован в виде технологической платформы с комплексом целевой аппаратуры. Технологическая платформа обеспечивает успешное выполнение задач целевой аппаратуры включающее в себя: 54 -Обеспечение энергетики КА; -Обеспечение ориентации космического аппарата в заданной системе координат; -Обеспечение вычисления и раздачи абонентам данных по времени, навигации и ориентации КА. Платформа содержит одну общую БВС для комплекса управления и системы ориентации. Такое решении позволяет существенно удешевить конструкцию КА, с другой стороны увеличивая сложность разработки бортового ПО. В качестве ОСРВ, используемой при разработке ПО для КА была выбрана VxWorks. Выбор был сделан исходя из следующих соображений: -Малое время переключения контекста – порядка 10-100 мкс; -Наличие необходимых драйверов устройств; -Размер системы – у VxWorks размер ядра равен 16 килобайтам; -Система приоритетов и вытесняющие алгоритмы диспетчеризации подходят для создания выбранной архитектуры ПО; -успешный опыт использования VxWorks в качестве ОС космического аппарата, как беспилотного, так и пилотируемого. В качестве архитектуры работы ПО была выбрана событийно-управляемая модель. Она позволяет эффективно использовать системные ресурсы, так как задачи прикладного ПО активизируются только при наступлении определенных для них типов событий. Все остальное время задача находится в ожидании наступления события, не тратя на свое обслуживание дополнительных ресурсов системы. VxWorks позволяет вести разработку на языках Си, C++, Ада. Для КА «Канопус-В» в качестве языка разработки был выбран язык программирования Си. Синтаксис Си известен подавляющему большинству программистов, а 55 количество реализованных с его использованием алгоритмов приближается к общему числу когда-либо запрограммированных алгоритмов. За годы прошедшие с момента создания данного языка он претерпел значительные изменения и прошел этап становления программирования. оптимизирующих в Программы, качестве основного написанные компиляторов по на скорости Си языка с системного использованием исполнения вплотную приближаются к написанным на языке ассемблера, но наряду с этим сохраняют переносимость и читаемость. Существенным недостатком языка си является отсутствие поддержки обработки исключений. С другой стороны отсутствует поддержка объектно-ориентированного программирования – любые абстракции данных приходится представлять при помощи структур, а обработку данных производить через передачу их в функции. Данное обстоятельство требует детальной проработки архитектуры программного обеспечения для недопущения его чрезмерного усложнения. Структуры данных, используемые для схожих операций таких как, например, передача сообщений, должны быть по возможности унифицированы. Ярким примером использования такого подхода является сама операционная система VxWorks. Так, например, для помещения произвольной пользовательской структуры во встроенный двусвязный список VxWorks достаточно добавить в объявление структуры два поля – указателя на предыдущий и последующий элементы, после чего функции, реализующие механизм работы с двусвязным списком, будут способны обслуживать пользовательскую структуру данных. 2.1. Архитектура бортового ПО Бортовое ПО построено на принципе выделения обособленных функций в отдельные, равнозначные задачи, отличающиеся приоритетом исполнения. 56 Получившаяся система является событийно-ориентированной системой мягкого реального времени и управляется следующими событиями: -прерывания по шине МКО; -прерывания по шине CAN; -прерывания по времени; -события – сообщение; -семафоры. Выбор событийно-управляемой системы снимает необходимость в разработке и реализации строгой последовательности исполнения задач в строго заданные интервалы, что делает ее более гибкой и предполагает возможность дальнейшего совершенствования. Система настроена на управление в 20 миллисекундном цикле, который был подобран опытным путем. Иными словами планировщик задач операционной системы раз в 20 миллисекунд проверяет очередь задач на исполнение на наличие более высокоприоритетной задачи и передает ей управление в случае наличия таковой. Операционная система позволяет изменить периодичность данной проверки, но стоит принять во внимание, что увеличение частоты опроса приведет к тому, что процессорное время будет в основном использоваться для частого переключения контекстов исполнения между ядром и пользовательскими задачами. Из-за используемой схемы с мягким реальным временем периодические процессы могут быть исполнены со сдвигом в 20 миллисекунд относительно расчетного из-за возможной высокой нагрузки системы. На данном КА такое смещение не является критичным, и потому допустимо. Очень важным является распределение приоритетов между задачами. VxWorks предоставляет в распоряжение разработчика возможность использования до 256 приоритетов. Неправильно установленные приоритеты могут привести к некорректному поведению системы в целом и даже к 57 невозможности работы по целевому назначению. Для возможности решения этой проблемы, в случае ее возникновения, VxWorks позволяет динамически изменять приоритет задачи. Тем не менее при неверно расставленных приоритетах может возникнуть ситуация взаимной блокировки, которая может привести к полной невозможности использования системы по целевому назначению. Вопрос с расстановкой приоритетов задачам должен иметь тщательную наземную проработку. Всего в ПО БВС выделено 18 задач. При старте системы, после инициализации, производимой средствами операционной системы, управление передается на пользовательскую точку входа. Данная точка входа является функцией которая запускает главную пользовательскую задачу – задачу обеспечения безопасности жизнедеятельности КА. Данная задача запускает заранее определенный набор приложений-задач, необходимых к исполнению после старта. Одной из важнейших базовых задач является задача ведения бортовой шкалы времени. Эта задача имеет наивысший приоритет и тактируется от системного таймера. Задача ведения времени реализует подписку любых других задач на периодическое оповещение о наступлении требуемого времени, тем самым обеспечивая выполнение периодических процессов с заданной частотой. Примером такого периодического процесса может служить опрос устройства цифровой обработки командной радиолинии о наличии команд управления. Другим примером может служить запуск очередного цикла управления в задаче обеспечения ориентации. В любой сложной информационной системе работа с памятью является важным и ответственным процессом, особенно все, что связано с ее выделением и последующим освобождением. Неосвобождение памяти может привести к неработоспособности системы. В сложных встраиваемых системах, требующих длительной наработки на отказ часто применяется отказ от динамической работы с памятью. Вместо этого память для всех ресурсов выделяют на этапе 58 кодирования, тем самым исключая ее утечки. Данный механизм, несомненно, имеет минусы, так как память для массивов часто приходится выделять не под конкретные элементы, а под возможные, тем самым уменьшая эффективность использования памяти. Построение такой системы сопряжено с расчетами требуемых ресурсов памяти, требующихся для автономного существования КА на срок определенный в техническом задании. Тем не менее, как показывает практика, проектирование системы со статическим распределением памяти позволяет быстро построить надежную и достаточно гибкую систему, лишенную множества трудновыявимых ошибок кодирования, связанных с динамическим управлением памятью. Для исполнения периодических функций используются системные механизмы сторожевых таймеров с рекурсивным перезапуском таймера, а также подписка на сообщения о наступлении определенного времени. Удобство второго механизма в том, что для его реализации необходимо только задать особый тип сообщения, рассылаемый задачей ведения бортовой шкалы времени и использовать его в уже работающем механизме обмена сообщениями. 2.2. Межзадачное взаимодействие и информационный обмен по шинам передачи данных Межзадачное взаимодействие организовано с использованием очередей сообщений и семафоров. Архитектурно каждая задача построена с использованием бесконечного цикла ожидания, получения, обработки вновь принятого сообщения. При этом чтение очередного сообщения из очереди является блокирующей операцией – следовательно при отсутствии новых сообщений задача передает управление операционной системе. Задача с более высоким, чем выполняющаяся в текущий момент, приоритетом, получившая очередное сообщение моментально получает управление, тем самым реализует 59 скорейшую обработку события-сообщения. Условно можно изобразить реализацию данной схемы в операционной системе VxWorks[12]: void A_task() { char can_exit=0; Queue_id = msgQCreate(MAX_MSGS_QUEUED, sizeof(tsMSGT_MESSAGE), MSG_Q_FIFO); while(can_exit==0) { msgLength=msgQReceive(Queue_id,(char*)&Command,sizeof(tsMSGT_MESSAGE), WAIT_FOREVER); …… } } 60 Блокирующее чтение Оправка сообщений Исполнение действий Выход Обработка Прием сообщений Цикл Запуск Инициализация задачи Выход из задачи Рис. 2.1 - Схема работы основного цикла задачи Вторым механизмом синхронизации задач являются семафоры. Семафоры используются для синхронизации доступа к ресурсу, а также для обеспечения удерживания задачи в определенном состоянии, до наступления требуемого события. При наступлении события, например прерывания, его обработчик может отпустить семафор, тем самым разрешая пользовательской задаче произвести работу. По завершении обработки задача вновь фиксируется на захвате семафора, ожидая его снятия. Семафоры используются там, где необходимо обеспечить высокую скорость обработки события, при этом напрямую невозможно 61 определить класс события, так как семафор не имеет информационной части. Для решения передачи информации о типе наступившего события могут быть использованы глобальные переменные, либо участки разделяемой памяти. Семафоры в основном применяются для обработки событий ввода-вывода и очередного такта таймера. Основным механизмом взаимодействия с оборудованием на космическом аппарате является взаимодействие по цифровым шинам передачи данных. На КА «Канопус-В» совместно используются 2 различных шины: CAN и MKO. Шина CAN используется для взаимодействия с блоками авионики. Каждый узел данной сети может быть многоадресным, что позволяет, используя лишь один CAN контроллер на устройстве обрабатывать группы сообщений с разными адресами получателя. Тем самым одно и то же устройство способно работать как несколько логических устройств. ПО БВС поделено на задачи, и каждая задача имеет определенный идентификатор CAN, и при посылке запросов к оборудованию данный идентификатор явно указывается в пакете. При получении обратного пакета, драйвер шины CAN пересылает сообщение в заданную очередь отравителя. Как видно из описания механизма взаимодействия задачи и оборудование авионики работают в общем адресном пространстве CAN, тем самым упрощая процедуру кодирования – ведь нет необходимости использовать разные протоколы для межзадачного и внешнего взаимодействий. Разумеется данный подход обязательно должен быть оптимизирован для передачи внутренних сообщений между задачами, исключающим физическую передачу по шине, используя вместо этого прямую передачу в очередь задачи-получателя. Для реализации данной идеи должен быть реализован сервис, обслуживающий шину CAN и все сопутствующие запросы, тем самым предоставляя единый интерфейс для посылки сообщений между задачами и между оборудованием. Второе немаловажное предназначение данного сервиса – буферизация сообщений для последующей передачи, а также буферизация входящих сообщений и последующая их маршрутизация до получателей. Передача сообщений с целью 62 последующей отправки по шине реализуется при помощи вызова функции с передачей в нее в качестве аргумента указателя на сообщение, инкапсулирующего в себе всю необходимую информацию. При вызове функция запрашивает из пула свободных сообщений очередное свободное сообщение и производит операцию глубокого копирования данных по указателю. Данная операция нужна из-за того что указатель на сообщение ссылается на стек задачи и сообщение может быть удалено раньше чем будет завершен цикл его обработки. Следующей операцией является помещение сообщения в список ожидающих отправки. При наступлении очередного цикла работы с шиной ПО производит отправку сообщений и помечает их как отправленные. В последствии ПО будет проверять статус каждого сообщения и при приходе на него ответа – отсылать его отправителю. При непоступлении ответа от получателя будет произведена повторная попытка отправки после неудачи которой сообщение будет помечено как свободное и возвращено в пул свободных сообщений, а отправителю будет направлено сообщение о таймауте передачи. Пул свободных сообщений Запрос свободного сообщения Сообщение на отправку Получение свободного сообщения Функция посылки сообщения Передача на шину Проверка таймаутов Освобождение сообщений Рис 2.2 - Схема передачи сообщения по шине CAN 63 Механизм работы по МКО схож с работой по CAN, но МКО является шиной с отличающимся арбитражем. Устройства на МКО могут работать в следующих состояниях: контроллер шины, оконечное устройство и монитор шины. Бортовая вычислительная система является контроллером шины и поэтому должна обеспечивать арбитраж и инициировать передачу данных. Механизмы передачи данных по МКО более строги и требуют тщательного проектирования. При поступлении сообщений на любую из шин будет сгенерировано прерывание. Обработчик прерывания является логической единицей сервисной части, обслуживающей шину и использует те же структуры данных при записи полученных сообщений. После получения сообщения и записи его в буфер, прерывание может завершить работу, отпустив при этом семафор, который в свою очередь позволит сервису обработки начать работу по разбору буферного массива и доставке сообщений до адресатов. Чтобы система функционировала корректно необходимо хранить состояние каждого отправленного сообщения с тем, чтобы возможно было определять ошибки информационного взаимодействия, организовывать повторную отправку, а также фиксировать таймауты передачи данных. 2.3. Живучесть - парирование отказов При работе космического аппарата на орбите возможно возникновение ряда нештатных ситуаций к которым ПО должно быть готово. Условно все нештатные ситуации можно разделить на две группы: -аппаратные отказы; -программные сбои. 64 Так к аппаратным отказам относятся перегрев оборудования, короткое замыкание в цепях питания, падение напряжения бортовой сети, полный отказ отдельных узлов. К программным сбоям можно отнести недостоверность сформированной приборами информации, программные исключения. Для контроля критически важных параметров КА желательно выделять отдельную задачу мониторинга. Целью данной задачи является автоматический сбор и диагностирование информации о состоянии КА и выдачу парирующие воздействия. Таковыми воздействиями могут быть, например, временная приостановка работы КА по целевому назначению, до анализа ситуации на Земле. При падении напряжения бортовой сети логичным действием является отключение энергоемких абонентов. При полном отказе какого либо узла необходимо провести процедуру перевода работы на дублирующий узел. При наличии избыточности, не подразумевающей дублирования оборудования (например, избыточность «3 из четырех»), ПО должно иметь алгоритмы динамически подстраивающиеся под сложившуюся ситуацию. Ситуация с отказом оборудования требует еще и точной локализации оказавшего узла. Для этого необходимо производить постоянный мониторинг состояния КА и при обнаружении отказа производить работу по его локализации путем перекрестного анализа показаний с приборов в течении определенного времени. Если отказ подтверждается по нескольким прямым или косвенным признакам необходимо произвести действия по автоматическому парированию отказа, а в случае если это не удается - перевести КА в энергетически безопасный режим до анализа ситуации. Исключительные ситуации возникают в пользовательских задачах и являются результатом невыровненное некорректной обращение к памяти, операции логарифм [1]: деление на отрицательного ноль, числа, переполнение стека и прочее. Для парирования таких ситуаций и сохранения работоспособности системы предусмотрены механизмы обработки исключительных ситуаций и связанные с ними обработчики исключений. При 65 возникновении исключения вырабатывается аппаратное прерывание, ловушка (trap) и сигнал операционной системы, которые перехватываются обработчиком исключений. Данный обработчик в общем случае определяет какая из задач вызвала исключение и выполняет некоторые действия для парирования каждого конкретного исключения. В ОС VxWorks после окончания работы обработчика исключения, вызвавшая исключение задача остается в приостановленном состоянии. Дальнейшее решение о перезапуске задачи должно осуществляться после анализа причины появления исключительной ситуации. 2.4. Возможности для развития и модернизации Любая система по возможности должна быть написана с возможностью повторного использования. Системы, используемые в КА, как нельзя лучше отвечают этому требованию. Экспериментально отработанные и имеющие опыт эксплуатации системы становятся фундаментом для дальнейшей модернизации при использовании на аппаратах аналогичного класса. Решения, примененные в рамках отдельной работы, в дальнейшем могут быть использованы полностью или частично при разработке и принципиально новых КА. Достигается такая возможность тщательной проработанностью архитектуры бортового ПО, разработкой принципов декомпозиции целевой задачи на функциональные модули, а также согласование протоколов обмена и стандартов кодирования. Таким образом любой утилитарный модуль системы может быть легко заменен на другой, необходимый в текущем проекте. Заимствование уже отработанного кода позволяет существенно ускорить разработку как программного кода систему, так и конструкторской и эксплуатационной документации. Использование единой системы позволяет упростить работу эксплуатирующего персонала. 66 Еще одним несомненным плюсом модульной архитектуры ПО является возможность замены модуля на уже запущенной системе с целью исправления ошибок в ПО, либо внесения новой функциональности. 2.5. Тестирование и отработка бортового ПО Тестированию и отработке ПО всегда уделялось огромное значение. Ведь именно на этом этапе появляется возможность установить корректность выбранных алгоритмов и правильность кодирования. В доцифровую эпоху, при разработке рулевых машин для ракет A4 немецкие инженеры использовали для моделирования полета простое устройство – маятник Хойзермана. В дальнейшем при проектировании отечественных ракет специалисты использовали электромеханическую модель – банмодель, разработанную немецким специалистом доктором Хохом[13]. При переходе на цифровую технику и с ростом мощностей ЭВМ появилась возможность использовать программно-математические модели, способные моделировать процессы протекающие на ракетах и КА, а также имитировать полет на любых его участках с достаточной точностью[1]. Моделирование позволяет получить достаточно надежные данные о работе системы управления КА более дешевыми средствами, чем испытание реального объекта. Моделирование является единственным методом изучения количественных и качественных сторон системы управления перед непосредственно полетом. К моделям систем предъявляются жесткие требования по достоверности имитации тех или иных процессов, одновременно моделирования. с этим определяется необходимая глубина Теоретическая математическая модель КА и полетной обстановки характеризуется степенью приближения имитационного процесса к реальным процессам, в связи с этим результаты имитационной отработки всегда носят частный характер. Тем не менее, этот метод является наиболее 67 эффективным методом исследования такой сложной системы как КА. Математическая имитационная модель должна обеспечивать: -моделирование работы всех бортовых систем КА и происходящих в них процессов; -реакция моделируемых систем на управляющие воздействия; -моделирование движения центра масс космического аппарата и вращения относительно центра масс; -моделирование окружающей обстановки: небесных светил, магнитного поля, звездного неба и т.д.; -генерирование полного потока телеметрической информации; -моделирование информационных связей между модулями и системами КА; -ввод нештатных ситуаций в модели систем и модулей КА. Сам процесс испытаний ПО можно разделить на частные и комплексные испытания. Частные испытания ставят перед собой целью испытать отдельные системы или подзадачи. Комплексные же испытания заключаются в совместной отработке работы всех систем. Сами испытания строятся по схеме с возрастанием показательности и ставят перед собой конечную цель натурного воссоздания штатной работы КА. Так на заключительных этапах тестирования производятся тестовые сценарии моделирующие первые сутки полета космического аппарата с выполнением им всех предусмотренных режимов и операций. Необходимо отметить что ряд систем, таких как ПО системы управления движением и навигацией, вообще не могут быть проверены до полета кроме как на имитационной модели. Создание модели наиболее достоверно моделирующей механические свойства космического аппарата и физических явлений, оказывающих на него воздействия является одним из наиболее критичных этапов разработки. 68 2.6. Документирование проекта Выпуск эксплуатационной документацией является одним из наиболее ответственных этапов разработки проекта. Неточности или отсутствие в документации достаточных для полноценного управления сведений может привести к возникновению нештатной ситуации. Эксплуатационная документация должна разрабатываться параллельно кодированию, а ее отработка осуществляться на этапе наземных испытаний. Одной из наиболее серьезных проблем является поддержание актуальности документации в процессе внесения изменений в код ПО. Одним из возможных решений является подробное документирование исходных программ с использованием специфических форматов комментариев, для возможности последующего автоматического построения описания структуры ПО и его составных частей. Данная информация может быть помещена в базу данных и дальнейшее формирование актуальной документации будет сопряжено с выборкой описаний из базы данных. Одной из наиболее известных систем генерации документации на основе исходных кодов является Doxygen - генератор документации для си-подобных языков (в основном) с открытым исходным кодом. Данная система позволяет проанализировать исходный код и построить документацию в различных форматах от html до postscript, что позволяет произвести дальнейшую автоматизированную обработку данных документов для генерации полноценной документации всего проекта в требуемом формате[31]. Использование специализированных ключевых слов в комментариях к исходному коду, позволяет впоследствии переносить их в документацию. Так, например, можно описать назначение функции, обозначить набор входных и выходных данных. При описании структуры можно описать все ее поля, и их назначение, список допустимых значений. Для сложных программных документирования является крайне желательным. 69 систем такой вид Другим сопутствующим видом исходных данных для написания документации могут являться комментарии в системе управления версиями исходного кода. Краткое описание каждой ревизии предоставляет дополнительный источник данных, необходимых для составления документации. 70 Заключение Космическая отрасль по своей природе является достаточно консервативной в выборе средств для построения бортовых комплексов управления и возможности их апостериорной (после запуска) модификации. Положительные результаты, полученные в ходе одного космического проекта, традиционно используются в рамках большого количества аналогичных космических аппаратов. Несмотря на это именно космонавтика является одним из основополагающих стимулов для развития техники и технологии построения сложных адаптивных систем управления, таких как БКУ КА. Постепенно на смену морально устаревающим программно временным устройствам приходят полноценные цифровые комплексы управления, основанные на использовании электронно-вычислительных машин. Основой эффективной работы с такой машиной является индустриальная, апробированная в десятках, а может быть и сотнях проектов операционная система реального масштаба времени. Прикладные задачи, связанные с управлением КА требуют от операционной системы быстрой реакции на асинхронно возникающие события и безотказности работы в течение всего срока существования КА. В связи миниатюризации с развитием появляются микроэлектроники классы малых и и общей микро тенденции к массогабаритных космических аппаратов. Это позволяет перейти к кластерным запускам. Так, например, кластерный запуск КА «Канопус-В» состоял из запуска собственно КА «Канопус-В», Белорусского космического аппарата - БКА, КА МКА ФКИ, TET1 и ADS-1B. Это приводит к увеличению объема наземной отработки – вместо одного-двух необходимо тестировать группу космических аппаратов. При этом чрезвычайно важно быть уверенным в базовых программных средствах, используемых в бортовой вычислительной системе. Надежность и успешный опыт их использования позволяют 71 в условиях дефицита времени сконцентрироваться на отработке алгоритмов работы КА, а не тратить время на отработку «сырых» операционной системы. Использование операционной системы реального времени на КА позволяет быстро разрабатывать и эффективно отлаживать прикладное ПО, а также иметь возможность повторного использования кода в последующих проектах. К тому же программное обеспечение использованием может формальных быть методов верифицировано и моделей (всесторонне, с проанализировано и протестировано) на Земле с использованием математических моделей сколь угодно высокой точности. Описанный в настоящей работе КА «Канопус-В» №1 в настоящее время успешно выполняет целевую задачу на околоземной орбите. Концепции заложенные при разработке его ПО позволяют использовать до 90 процентов его кода в бортовом разрабатывающегося в настоящее время ПО КА «Михайло Ломоносов», запуск которого запланирован на 2013 год. Разработка программного обеспечения больших проектов всегда представляет трудную инженерную задачу. В настоящее время при разработке космических аппаратов широко применяются хорошо зарекомендовавшие себя аппаратные разработки. До 80 процентов приборов установленных на КА являются частично модифицированными, либо применяются без изменений. В таких условиях написание бортового модульного ПО является жизненно необходимым. Часто аппаратно космический аппарат готов к запуску задолго до окончания разработки ПО. Использование ОСРВ позволяет существенно снизить временные затраты на разработку бортового программного кода. В настоящей работе приведены качественные и количественные аргументы в пользу выбора операционной системы VxWorks. Правильность выбора подтверждена созданием и эксплуатацией космических аппаратов «Канопус-В» и БКА, а также использованием созданной базовой платформы в процессе создания КА «Михайло Ломоносов». 72 Список сокращений БВС – Бортовая вычислительная система ПО – программное обеспечение АСН – автономная система навигации СОС – система ориентации и стабилизации СУДН – система управления движением и навигацией СД – Слово данных ОЗУ – оперативное запоминающее устройство БОИ – Блок обработки информации НКУ – Наземный комплекс управления КПИ – Командно-программная информация КА – Космический аппарат ДМ – Двигатель-маховик ОСРВ – Операционная система реального времени БКУ – Бортовой комплекс управления ИСЗ – Искусственный спутник Земли МКО - Мультиплексный канал обмена (шина MIL-STD-1553) CAN – Controller Area Network (шина CAN) 73 СПИСОК ИСТОЧНИКОВ 1. Микрин Е.А. Бортовые комплексы управления космическими аппаратами и проектирование их программного обеспечения.-М.: Издательство МГТУ им. Н.Э. Баумана, 2003. – 336с. 2. Getting Started With RTEMS 4.10.2 http://www.rtems.org 3. RTEMS C User’s Guide 4.10.99.0 http://www.rtems.org 4. An Architectural Overview Of QNX ISBN 1-88046-42-1 5. Операционная система реального времени QNX Neutrino 6.3. Системная архитектура: Пер. с англ. – СПб.:БХВ-Петербург, 2006 – 336с. 6. Таненбаум Э. Современные операционные системы. 3-е изд. – СПб:Питер, 2010. – 1120с. 7. Dr. Jurgen Sauermann, Melanie Thelen - Realtime Operating Systems. Concepts and Implementation of Microkernels for Embedded Systems 8. Сулейманова А.М. Системы реального времени: учебное пособие – Уфимск. Гос. авиац. техн. ун-т. – Уфа, 2004. – 292 с. 9. И.Б. Бурдонов, А.С. Косачев, В.Н. Пономаренко – Операционные системы реального времени www.ispras.ru/ru/preprints/docs/prep_14_2006.pdf 10. Таненбаум Э., Вудхалл А. Операционные системы. Разработка и реализация. Классика CS. 3-е изд. – СПб:Питер, 2007. – 704с. 11. Васильев В.Н. Космические аппараты дистанционного зондирования Земли – М.: ФГУП «НПП ВНИИЭМ», 2009. – 310 с. 12. http://www.windriver.com/products/product-overviews/PO_WB_1110.pdf 13. Б.Е. Черток, Ракеты и люди. Том 1. – М:РТСофт, 2006г. – 384с. 14. Christof Wehner, Tornado and VxWorks. ISBN 978-3833410697. 15. http://www.windriver.com/products/product-overviews/PO_VE_DO178_0109.pdf 16. Таненбаум Э., Архитектура компьютера.5-е изд. – СПб:Питер, 2007 – 844с. 17. ГОСТ Р 52070-2003 Интерфейс магистральный последовательный системы электронных модулей. – Введ. 2003-06-05. М: Издательство стандартов 74 18. Бровкин А.Г., Бурдыгов Б.Г., Гордийко С.В. и др. Бортовые системы управления космическими аппаратами: Учебное пособие – М.: Изд-во МАИ-ПРИНТ 2010. – 304с. 19. http://www.sparc.com/standards/V8.pdf 20. Б.В. Раушенбах, Е.Н. Токарь. Управление ориентацией космических аппаратов. М: Наука, Главная редакция физико-математической литературы, 1974, 600с. 21. В.В. Белецкий. Движение искусственного спутника относительно центра масс. М: Наука, 1965. 416с. 22.http://www-cdfonline.fnal.gov/daq/computing/vxworks/Vx53Guide.pdf 23. https://lwn.net/Articles/146861/ 24. https://rt.wiki.kernel.org/index.php/CONFIG_PREEMPT_RT_Patch 25. Брукс Ф, Мифический человеко-месяц, или Как создаются программные системы. – М: Символ-плюс, 2007. 304с. 26. Робачевский А., Немнюгин С., Стесик О. Операционная система UNIX. – СПб:БХВ-Петербург, 2010, 656с. 27.http://www.acmesystems.it/download/libri/Pro%20Linux%20Embedded%20Syst ems.pdf 28. http://esd.cs.ucr.edu/webres/can20.pdf 29. http://www.ssau.ru/files/resources/sotrudniki/rts2008.pdf 30. Гома Х. UML Проектирование систем реального времени, распределенных и параллельных приложений., М:ДМК Пресс, 2011. -700с. 31.http://www.digilife.be/quickreferences/QRC/Doxygen%20Quick%20Reference.p df 32. Коллектив авторов – Космический комплекс оперативного мониторинга техногенных и природных чрезвычайных ситуаций «Канопус-В» с космическим аппаратом «Канопус-В» №1 – М: ФГУП «НПП ВНИИЭМ», 2011. - 110с. 75 Приложение А Пример протокола информационного обмена по шине МКО Формат сообщения «Запрос ТМИ» Цель обмена – запрос текущих ТМ параметров по заданным адресам ОЗУ («зеркала») БОИ. Для данного обмена используется формат 1 основных сообщений. Сообщение имеет следующий вид: КС 15 14 13 12 11 10 9 8 7 6 5 0 0 0 0 1 0 0 0 0 1 1 4 3 2 1 0 Кол-во СД (n) СД1 ............. СД n-1 Контрольная сумма (СД1-СДn-1) CД n ОС 0 0 0 0 1 0 0 0 0 0 0 6 5 0 0 0 0 0 Кодировка 1-31СД массива режима ВД: 15 14 13 12 11 10 9 8 7 Номер датчика (тип 0)/Адрес ячейки ОЗУ БОИ (тип 1) 4 Номер ЛК (тип 0)/Адрес страницы ОЗУ БОИ (тип 1) 76 3 2 1 Тип данных (0/1) 0 Приложение Б Тип данных 0 0 16 Беззнаковое - Время: Сутки 1 5 11 Беззнаковое - Время: Часы 1 0 5 Беззнаковое - Время: Минуты 2 6 6 Беззнаковое - Время: Секунды 2 0 6 Беззнаковое - Признаки состояния ДМ1 3 8 8 Беззнаковое [] Признаки состояния ДМ2 3 0 8 Беззнаковое [] Признаки состояния ДМ3 4 8 8 Беззнаковое [] Признаки состояния ДМ4 4 0 8 Беззнаковое [] Заданная скорость ДМ1 5 0 16 Знаковое об/ мин Заданная скорость ДМ2 6 0 16 Знаковое об/ мин Заданная скорость ДМ3 7 0 16 Знаковое об/ мин Заданная скорость ДМ4 8 0 16 Знаковое об/ мин Измеренная скорость ДМ1 9 0 16 Знаковое об/ мин Измеренная скорость ДМ2 10 0 16 Знаковое об/ мин Измеренная скорость ДМ3 11 0 16 Знаковое об/ мин Измеренная скорость ДМ4 12 0 16 Знаковое об/ мин 77 Единицы измерения Длина (бит) Идентификатор пакета Телеметрируемый параметр Номер слова Стартовый бит Пример телеметрического пакета Приложение В Пример снимка, полученного с КА 78

Оглавление

Related documents

Products

Support

Оглавление

Related documents

Add this document to collection(s)

Add this document to saved

Suggest us how to improve StudyLib