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

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

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

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

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

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

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

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

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

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

Поставив шаттлы на крыло, руководство 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 и Массачусетском Технологическом Институте.

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

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

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

К оглавлению

Терралаб

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

Олег Нечай

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

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