Цифровой журнал «Компьютерра» № 80 - Коллектив Авторов

Итак, 10 марта 1973 года космическое агентство заключило контракт с компанией IBM, которая выступала в качестве головного подрядчика программной системы PASS. Поскольку программисты IBM не сильно смыслили в авионике, им в помощь придавались ударные силы разработчиков Rockwell. Ну и в качестве консультирующией стороны, имеющей опыт разработки космического софта, привлекалась лаборатория Дрепера.

Участие в проекте множества рабочих групп легко могло привести к хаосу и бесконечным, бессмысленным сражениям и «перетягиванию одеяла». Поэтому в NASA чётко разграничили полномочия участников проекта, определив, какие типы документов делает каждый из них. Было предложено использовать три уровня документов, обозначавшихся соответственно "А", "В" и "С". Документы уровня "А" разрабатывались программистами IBM и содержали описание общей структуры системы PASS и функции её базовых модулей. Уровень "В" тоже создавался айбиэмовцами, но при поддержке специалистов из Intermetrics. В этих документах структура и функции модулей детализировались вплоть до конкретных параметров и используемых структур языка HAL/S. За уровень "С" отвечали разработчики Rockwell. Используя свой опыт проектирования систем авионики, они предлагали конкретную реализацию той или иной подпрограммы. Зачастую излишне конкретную. Как сказал один из участников проекта, видимо, из-за срыва единоличного контракта ребята из Rockwell давали бумаги, описывающие не «что делать», а «как делать».

Такое разделение полномочий в реализации сложного проекта позволило поддерживать заданные сроки реализации и концептуальную целостность системы PASS. Чуть позже подобный подход станет широко применяться в CASE-системах. Впрочем, этот подход не спас проект от перерасхода бюджета. Вместо запланированных изначально двадцати миллионов долларов проектирование PASS «скушало» ровно в десять раз больше.

Система FCOS и оверлеи. Мало, но достаточно

Что же собой представляет PASS? Как и в случае любой другой программной среды, PASS включает в себя системные и прикладные компоненты.

К системным относятся: операционная система FCOS (Flight Computer Operational System) и интерфейс пользователя, позволяющий астронавтам взаимодействовать с PASS. Пользовательские же программы весьма разнообразны и могут меняться от миссии к миссии. Среди них есть и «долгоиграющие» варианты, например софт для ориентации, навигации и управления кораблём в полёте (GN&C — Guidance, Navigation, Control) и для управления и проверки таких систем корабля, как шасси, двигатели, грузовой отсек и роботизированный манипулятор (SM — System Management и VCO — Vehicle CheckOut). К прикладным программам относился и софт, специфичный для каждого этапа миссии.

Обобщённое представление архитектуры операционной системы 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? Уверен, что проверенный временем код этой программной системы авионики найдёт своё применение в будущих проектах пилотируемого освоения космического пространства.

К оглавлению

Терралаб

Восемь жидкокристаллических дисплеев

Олег Нечай

Опубликовано 05 августа 2011 года

Acer V223W

Доступный монитор на базе TN-матрицы, рассчитанный на домашнее и офисное использование.