Обобщённое представление архитектуры операционной системы FCOS

Сердцем всей системы, естественно, является FCOS. Приступая к её проектированию, в NASA вели длительные споры об архитектуре ядра этой системы. Компания Rockwell настаивала на архитектуре с разделением времени, где для каждого процесса выделяется квант времени длительностью сорок миллисекунд. IBM совместно с Intermetrics предлагала систему реального времени, в которой прерывание работы процессов выполнялось по приоритетам. Резон был и том и в другом предложении. В результате FCOS получилась гибридной. Основной цикл работы её диспетчера составляет 960 миллисекунд. В рамках этого «медленного» цикла выполняется множество высокочастотных циклов длительностью в 40 миллисекунд каждый. В том случае, если при выполнении программы появляется процесс с более высоким приоритетом, программа немедленно прерывается с сохранением своего слова состояния (PSW — Program Status Word). Программы, ожидающие завершения операций ввода-вывода, помещаются в очередь низкоприоритетных с постепенным повышением приоритета. Такой подход позволил реализовать в FCOS режим выполнения задач, близкий к реальному времени. Стоит напомнить, что за окном был 1975 год и многозадачность с разделением времени только набирала обороты.

Компоненты FCOS в деталях

FTOS была полностью разработана на ассемблере и занимала всего 35 килобайт ферритовой памяти AP-101, резидентно находясь в ней на протяжении всей миссии. Программы GN&C, SM и VCO создавались на HAL/S и составляли так называемую базу главных функций (MFB — Major Function Base).

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

Оверлейные модули OPS хранились на устройстве внешней памяти и подгружались в память AP-101 по мере необходимости

Эти модули получили название «Последовательность операций» (OPS — Operational Sequence), и хранились они на ленточном устройстве внешней памяти (MMU — Mass Memory Unit). Каждый OPS отвечал за конкретный этап миссии, например за старт корабля, его работу на орбите или посадку. Структурно OPS состоял из базовых (Major Mode), специальных (Spec) функций и функции визуализации (Disp). Функции Spec содержали уникальные для каждой миссии параметры, отображаемые на дисплеях экипажа соответствующими функциями Disp.

Результат работы функций Disp на экране экипажа при выполнении OPS-2

Разработчикам пришлось серьёзно попотеть, чтобы умудриться делать каждую OPS меньше 106 килобайт имевшийся памяти. Например, в 1975 году первоначальный вариант программы старта корабля составлял 140 килобайт, к 1978 году модуль удалось уменьшить до 116 килобайт при требовании NASA в 80 килобайт. В результате дальнейшей оптимизации стартовый OPS стал занимать 98840 слов.

Схема последовательности использования OPS для миссии STS-1

Благодаря модульному подходу система PASS получилась гибко настраиваемой средой, которая непрерывно развивалась и совершенствовалась в течение всех тридцати лет существования проекта STS. К моменту старта первой миссии STS-1 в 1981 году было разработано более тысячи разнообразных OPS. За первые двенадцать миссий около пятидесяти процентов кода этих OPS было переработано с учётом его реальной эксплуатации системы PASS.

NASA Sortware Production Facility. Фабрика байтов

Поставив шаттлы на крыло, руководство NASA осознало важность постоянного создания и совершенствования программ для многочисленных миссий STS. Именно поэтому имеющийся тогда отдел программирования был преобразован в лабораторию NASA Software Development Laboratory, которая в 1982 году превратилась в «фабрику» (SPF — Software Production Facility), на «конвейере» которой непрерывно создавались, отлаживались и модифицировались OPS и системные компоненты PASS.

Первоначально SPF состояла из: пяти ЭВМ IBM 360/75, совместимых по системе команд с AP-101, трёх AP-101, связанных между собой в избыточную структуру, подключённую к модулю управления оборудованием корабля (FEID — Flight Equipment Interface Device), и средства моделирования полёта — имитатора кабины шаттла с шестью степенями свободы.

В 1981 году состав оборудования SPF дополнился двумя мощными ЭВМ IBM 3033 с шестнадцатью миллионами байт памяти каждая, двадцатью ленточными накопителями, шестью принтерами и жёсткими дисками общим объёмом 23,4 миллиарда байтов (примерно 22 Гб).

К этой системе в самой SPF было подключено сто пять терминалов. Дополнительные терминалы располагались у коллег по разработке: в центрах космических полётов Годдарда, Маршалла и Кеннеди, а также в компании Rockwell и Массачусетском Технологическом Институте.

IBM 3033

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

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

А что же PASS? Уверен, что проверенный временем код этой программной системы авионики найдёт своё применение в будущих проектах пилотируемого освоения космического пространства.

К оглавлению

Терралаб

Добавить отзыв
ВСЕ ОТЗЫВЫ О КНИГЕ В ИЗБРАННОЕ

0

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

Отметить Добавить цитату