Компьютерра PDA N125 (30.07.2011-05.08.2011)

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

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

Один из многочисленных документов уровня "С" для первой (STS-1) миссии шаттла

Такое разделение полномочий в реализации сложного проекта позволило поддерживать заданные сроки реализации и концептуальную целостность системы 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 по мере необходимости