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

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

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

-таймеры;

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

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

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

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

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

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

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

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

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

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

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

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

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, причиной этому послужила необходимость пересмотра довольно старого на текущий момент DO-178B в соответствии с текущим развитием информационных технологий и программного обеспечения. Стандартом предусмотрено пять уровней описания степени серьезности отказа, и для каждого из данных уровней определен набор требований к программному обеспечению, которые должны гарантировать работоспособность всей системы в целом при возникновении отказов данного уровня отказа. Данный стандарт основывается на методе оценки опасности, которую может вызвать неправильная работы системы в первую очередь для пассажиров и экипажа воздушного судна, и определяет следующие уровни сертификации:

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

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

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

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

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

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

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

1.8.3 ARINC-653

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

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

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

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

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

-VxWorks;

-QNX;

-RTEMS;

-RT-Preempt Linux.

1.9.1 VxWorks

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

-x86;

-MIPS;

-PowerPC ;

-Freescale ColdFire ;

-Intel i960 ;

-SPARC;

-Fujitsu FR-V;

-SH-4.

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

Среда разработки и набор компиляторов позволяют вести кросс-разработку ПО для VxWorks на языках Си, C++, Ada, Java.

1.9.2 RTEMS

Операционная система RTEMS представляет собой полнофункциональную ОСРВ с открытым исходным кодом. В первоначальном своем варианте система разрабатывалась по заказу министерства обороты США[2] для использования в крылатых ракетах. В настоящий момент разработкой системы руководит компания 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;

-Поддержка целого ряда файловых систем:

-Корневая виртуальная ФС размещаемая в ОЗУ In-Memory Filesystem (IMFS);

-FAT;

-NFS;

-RFS (RTEMS file system) родная файловая система RTEMS.

-Поддержка многозадачности;

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

-Событийно-управляемая, приоритетная, вытесняющая многозадачность;

-Поддержка rate monotonic scheduling (RMS);

-Наследование приоритетов;

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

-динамическое выделение памяти;

-динамическая загрузка и связывание модулей;

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

-Очереди сообщений;

-Механизм сигналов;

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

1.9.3 QNX

Одна из самых известных операционных систем основанная на технологии микроядра. Первый релиз системы состоялся в 1982 году. В настоящее время считается хорошо проработанной системой содержащей минимальное количество ошибок. QNX идеально подходит для встраиваемых приложений реального времени. Она может быть масштабирована до самых компактных конфигураций и способна работать в многозадачном режиме, управлять потоками, осуществлять планирование процессов по приоритетам и выполнять быстрое переключение контекста. Более того операционная система предоставляет все эти возможности посредством программного интерфейса, основанного на стандартах POSIX[4]. Таким образом, компактность системы достигается не в ущерб стандартам. Кроме того, QNX обладает достаточной гибкостью в настройке. Разработчик может легко изменять ее конфигурацию в соответствии с требованиями создаваемых приложений. При разработке можно использовать только те ресурсы, которые необходимы для конкретной задачи, изменяя систему в диапазоне от минимальной конфигурации микроядра с несколькими базовыми модулями до полнофункциональной сетевой системы, предназначенной для обслуживания сотен пользователей.

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

-управление потоками посредством POSIX-примитивов для создания потоков;

-управление сигналами;

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

-синхронизацию посредством примитивов синхронизации потоков;

-планирование;

-управление таймерами;

-управление процессами.

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

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

-администраторы файловых систем;

-администраторы устройств символьного ввода-вывода;

-графический сервер;

-сетевой администратор;

-стек протоколов TCP/IP.

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

1.9.4 RT-Preempt-Linux

Популярная UNIX-подобная операционная система с открытым исходным кодом. Система построена, в отличие от большинства современных ОСРВ, на основе монолитного ядра с возможностью загрузки и выгрузки отдельных модулей. Стандартное ядро Linux полностью отвечает только требованиям мягкого реального времени: оно предоставляет основные операции POSIX управления временем исполнения для пользовательского уровня, но отнюдь не гарантирует выполнения за жестко фиксированное время. С патчем к ядру RT-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 является то, что в общем случае нет даже необходимости перекомпилировать приложения для исполнения их в режиме реального времени, также не требуется запуск от имени суперпользователя. Тем не менее, для специфических возможностей по использованию реального времени все же требуется перекомпиляция приложений, и написание специальных приложений для работы в реальном времени.

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

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

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

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

-среда разработки WindRiver Workbench - используемая для разработки под VxWorks[12];

-QNX Momentics Tool Suite;

-плагин Eclipse для разработки под RTEMS[2].

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

-редактирование исходного кода;

-возможность использования системы контроля версий;

-статистический анализ кода;

-гибкая настраиваемость;

-поддержка плагинов ;

-настройка специфических параметров системы.

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

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

Таблица 1.1 - Сравнение выбранных операционных систем

	VxWorks	QNX	RTEMS	RT-LINUX
Поддерживаемые платформы	x86, PowerPC, ARM, MIPS, 68K, CPU 32, ColdFire, MCORE, Pentium, i960, SH, SPARC, NEC V8xx, M32 R/D, RAD6000, ST 20, TriCore	X86, ARM, XScale, PowerPC, MIPS	X86,Arm,AVR,i960,MC68,Coldfire, PowerPC,SPARC	X86, ARM,Xscale
Архитектура системы	Клиент-серверная. Микроядро.	Клиент-серверная. Микроядро.	Иерархическая многослойная с микроядром	Монолитная
Размер ядра	16 кб (версия 5.4) 150 кб (версия 6)	От 7 кб	150 кб	От 300 кб
Число уровней приоритетов	256	256	256	40
Политики планирования	FIFO с приоритетами, циклическое, адаптивное, спорадическое планирование	FIFO с приоритетами, циклическое, адаптивное, спорадическое планирование	FIFO с приоритетами, циклическое, адаптивное, спорадическое планирование, RMS	FIFO с приоритетами, циклическое, адаптивное, спорадическое планирование
Максимальное число задач	Неограничено	Неограничено	Неограничено	Неограничено



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

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

-Взаимодействие с объектом управления в интерактивном режиме;

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

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

-Работа с прерываниями, количество и время появления которых является случайным;

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

-работа в режиме теледоступа;

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

Программное обеспечение бортовой вычислительной системы должно строится по модульному принципу. Модульный принцип проектирования ПО связан с процессом синтеза системы как совокупности слабосвязанных компонент, допускающих их относительно независимую разработку и использование. Проблемы декомпозиции системы на подсистемы, задачи на подзадачи, программного обеспечения на отдельные программы и подпрограммы, возникают на различных этапах анализа и синтеза систем управления. Использование принципа модульности при проектировании программного обеспечения космического аппарата позволяет свести проектирование к оптимальному синтезу функционально-независимых отдельных модулей, совместно выполняющих заданные функции системы с требуемой эффективностью, и значительно сокращает затраты на разработку, внедрение и модификацию систем. При проектировании модульных систем должны быть обеспечены такие основные их свойства, как: функциональность, связность, алгоритмичность, последовательность, маскировка. Любые параметры, влияющие на управление и управляемость КА должны иметь возможность конфигурации. Единожды жестко установленные на Земле значения параметров впоследствии эксплуатации могут становиться неприемлемыми и требовать коррекции. Наиболее оптимальным вариантом передачи конфигурационных параметров на борт могут служить специально определенные виды командно-программной информации.

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

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

Операционная система реального времени, используемая на КА должна отвечать следующим требованиям:

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

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

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

-Возможность создания бездисковой конфигурации;

-Наличие необходимых драйверов устройств;

-Малый размер системы;

-Поддержка необходимых механизмов диспетчеризации и назначения приоритетов;

-Развитые средства межзадачного взаимодействия;

-Средства реализации служб времени.

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

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

-Обеспечение энергетики КА;

-Обеспечение ориентации космического аппарата в заданной системе координат;

-Обеспечение вычисления и раздачи абонентам данных по времени, навигации и ориентации КА.

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

-Малое время переключения контекста - порядка 10-100 мкс;

-Наличие необходимых драйверов устройств;

-Размер системы - у VxWorks размер ядра равен 16 килобайтам;

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

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

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

VxWorks позволяет вести разработку на языках Си, C++, Ада. Для КА «Канопус-В» в качестве языка разработки был выбран язык программирования Си. Синтаксис Си известен подавляющему большинству программистов, а количество реализованных с его использованием алгоритмов приближается к общему числу когда-либо запрограммированных алгоритмов. За годы прошедшие с момента создания данного языка он претерпел значительные изменения и прошел этап становления в качестве основного языка системного программирования. Программы, написанные на Си с использованием оптимизирующих компиляторов по скорости исполнения вплотную приближаются к написанным на языке ассемблера, но наряду с этим сохраняют переносимость и читаемость. Существенным недостатком языка си является отсутствие поддержки обработки исключений. С другой стороны отсутствует поддержка объектно-ориентированного программирования - любые абстракции данных приходится представлять при помощи структур, а обработку данных производить через передачу их в функции. Данное обстоятельство требует детальной проработки архитектуры программного обеспечения для недопущения его чрезмерного усложнения. Структуры данных, используемые для схожих операций таких как, например, передача сообщений, должны быть по возможности унифицированы. Ярким примером использования такого подхода является сама операционная система VxWorks. Так, например, для помещения произвольной пользовательской структуры во встроенный двусвязный список VxWorks достаточно добавить в объявление структуры два поля - указателя на предыдущий и последующий элементы, после чего функции, реализующие механизм работы с двусвязным списком, будут способны обслуживать пользовательскую структуру данных.

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

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

-прерывания по шине МКО;

-прерывания по шине CAN;

-прерывания по времени;

-события - сообщение;

-семафоры.

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

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

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

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

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

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

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

Межзадачное взаимодействие организовано с использованием очередей сообщений и семафоров. Архитектурно каждая задача построена с использованием бесконечного цикла ожидания, получения, обработки вновь принятого сообщения. При этом чтение очередного сообщения из очереди является блокирующей операцией - следовательно при отсутствии новых сообщений задача передает управление операционной системе. Задача с более высоким, чем выполняющаяся в текущий момент, приоритетом, получившая очередное сообщение моментально получает управление, тем самым реализует скорейшую обработку события-сообщения. Условно можно изобразить реализацию данной схемы в операционной системе 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);

……

}

}



Рис. 2.1 - Схема работы основного цикла задачи

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

Основным механизмом взаимодействия с оборудованием на космическом аппарате является взаимодействие по цифровым шинам передачи данных. На КА «Канопус-В» совместно используются 2 различных шины: CAN и MKO. Шина CAN используется для взаимодействия с блоками авионики. Каждый узел данной сети может быть многоадресным, что позволяет, используя лишь один CAN контроллер на устройстве обрабатывать группы сообщений с разными адресами получателя. Тем самым одно и то же устройство способно работать как несколько логических устройств. ПО БВС поделено на задачи, и каждая задача имеет определенный идентификатор CAN, и при посылке запросов к оборудованию данный идентификатор явно указывается в пакете. При получении обратного пакета, драйвер шины CAN пересылает сообщение в заданную очередь отравителя. Как видно из описания механизма взаимодействия задачи и оборудование авионики работают в общем адресном пространстве CAN, тем самым упрощая процедуру кодирования - ведь нет необходимости использовать разные протоколы для межзадачного и внешнего взаимодействий. Разумеется данный подход обязательно должен быть оптимизирован для передачи внутренних сообщений между задачами, исключающим физическую передачу по шине, используя вместо этого прямую передачу в очередь задачи-получателя. Для реализации данной идеи должен быть реализован сервис, обслуживающий шину CAN и все сопутствующие запросы, тем самым предоставляя единый интерфейс для посылки сообщений между задачами и между оборудованием. Второе немаловажное предназначение данного сервиса - буферизация сообщений для последующей передачи, а также буферизация входящих сообщений и последующая их маршрутизация до получателей. Передача сообщений с целью последующей отправки по шине реализуется при помощи вызова функции с передачей в нее в качестве аргумента указателя на сообщение, инкапсулирующего в себе всю необходимую информацию. При вызове функция запрашивает из пула свободных сообщений очередное свободное сообщение и производит операцию глубокого копирования данных по указателю. Данная операция нужна из-за того что указатель на сообщение ссылается на стек задачи и сообщение может быть удалено раньше чем будет завершен цикл его обработки. Следующей операцией является помещение сообщения в список ожидающих отправки. При наступлении очередного цикла работы с шиной ПО производит отправку сообщений и помечает их как отправленные. В последствии ПО будет проверять статус каждого сообщения и при приходе на него ответа - отсылать его отправителю. При непоступлении ответа от получателя будет произведена повторная попытка отправки после неудачи которой сообщение будет помечено как свободное и возвращено в пул свободных сообщений, а отправителю будет направлено сообщение о таймауте передачи.

Рис 2.2 - Схема передачи сообщения по шине CAN



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

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

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

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

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

-аппаратные отказы;

-программные сбои.

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

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

Исключительные ситуации возникают в пользовательских задачах и являются результатом некорректной операции [1]: деление на ноль, невыровненное обращение к памяти, логарифм отрицательного числа, переполнение стека и прочее. Для парирования таких ситуаций и сохранения работоспособности системы предусмотрены механизмы обработки исключительных ситуаций и связанные с ними обработчики исключений. При возникновении исключения вырабатывается аппаратное прерывание, ловушка (trap) и сигнал операционной системы, которые перехватываются обработчиком исключений. Данный обработчик в общем случае определяет какая из задач вызвала исключение и выполняет некоторые действия для парирования каждого конкретного исключения. В ОС VxWorks после окончания работы обработчика исключения, вызвавшая исключение задача остается в приостановленном состоянии. Дальнейшее решение о перезапуске задачи должно осуществляться после анализа причины появления исключительной ситуации.

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

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

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



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

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

В доцифровую эпоху, при разработке рулевых машин для ракет A4 немецкие инженеры использовали для моделирования полета простое устройство - маятник Хойзермана. В дальнейшем при проектировании отечественных ракет специалисты использовали электромеханическую модель - банмодель, разработанную немецким специалистом доктором Хохом[13]. При переходе на цифровую технику и с ростом мощностей ЭВМ появилась возможность использовать программно-математические модели, способные моделировать процессы протекающие на ракетах и КА, а также имитировать полет на любых его участках с достаточной точностью[1]. Моделирование позволяет получить достаточно надежные данные о работе системы управления КА более дешевыми средствами, чем испытание реального объекта. Моделирование является единственным методом изучения количественных и качественных сторон системы управления перед непосредственно полетом. К моделям систем предъявляются жесткие требования по достоверности имитации тех или иных процессов, одновременно с этим определяется необходимая глубина моделирования. Теоретическая математическая модель КА и полетной обстановки характеризуется степенью приближения имитационного процесса к реальным процессам, в связи с этим результаты имитационной отработки всегда носят частный характер. Тем не менее, этот метод является наиболее эффективным методом исследования такой сложной системы как КА. Математическая имитационная модель должна обеспечивать:

-моделирование работы всех бортовых систем КА и происходящих в них процессов;

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

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

-моделирование окружающей обстановки: небесных светил, магнитного поля, звездного неба и т.д.;

-генерирование полного потока телеметрической информации;

-моделирование информационных связей между модулями и системами КА;

-ввод нештатных ситуаций в модели систем и модулей КА.

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

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

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

Выпуск эксплуатационной документацией является одним из наиболее ответственных этапов разработки проекта. Неточности или отсутствие в документации достаточных для полноценного управления сведений может привести к возникновению нештатной ситуации. Эксплуатационная документация должна разрабатываться параллельно кодированию, а ее отработка осуществляться на этапе наземных испытаний. Одной из наиболее серьезных проблем является поддержание актуальности документации в процессе внесения изменений в код ПО. Одним из возможных решений является подробное документирование исходных программ с использованием специфических форматов комментариев, для возможности последующего автоматического построения описания структуры ПО и его составных частей. Данная информация может быть помещена в базу данных и дальнейшее формирование актуальной документации будет сопряжено с выборкой описаний из базы данных. Одной из наиболее известных систем генерации документации на основе исходных кодов является Doxygen - генератор документации для си-подобных языков (в основном) с открытым исходным кодом. Данная система позволяет проанализировать исходный код и построить документацию в различных форматах от html до postscript, что позволяет произвести дальнейшую автоматизированную обработку данных документов для генерации полноценной документации всего проекта в требуемом формате[31]. Использование специализированных ключевых слов в комментариях к исходному коду, позволяет впоследствии переносить их в документацию. Так, например, можно описать назначение функции, обозначить набор входных и выходных данных. При описании структуры можно описать все ее поля, и их назначение, список допустимых значений. Для сложных программных систем такой вид документирования является крайне желательным.

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



Заключение

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

В связи с развитием микроэлектроники и общей тенденции к миниатюризации появляются классы малых и микро массогабаритных космических аппаратов. Это позволяет перейти к кластерным запускам. Так, например, кластерный запуск КА «Канопус-В» состоял из запуска собственно КА «Канопус-В», Белорусского космического аппарата - БКА, КА МКА ФКИ, TET1 и ADS-1B. Это приводит к увеличению объема наземной отработки - вместо одного-двух необходимо тестировать группу космических аппаратов. При этом чрезвычайно важно быть уверенным в базовых программных средствах, используемых в бортовой вычислительной системе. Надежность и успешный опыт их использования позволяют в условиях дефицита времени сконцентрироваться на отработке алгоритмов работы КА, а не тратить время на отработку «сырых» операционной системы.

...