Система PASS: софт для шаттла Евгений Лебеденко, Mobi.ru
Система PASS: софт для шаттла
Евгений Лебеденко, Mobi.ru
Опубликовано 02 августа 2011 года
Если отладка — процесс удаления ошибок, то программирование должно быть процессом их внесения.
Э. Дейкстра
Порой, после очередного зависания Windows, не осилившей коктейль из множества запущенных процессов, задумываешься о том, каким же надёжным должно быть программное обеспечение, которое трудится там, где человеку ежесекундно угрожает смертельная опасность. Например, в космическом пространстве.
Программный код, написанный людьми, управляет системами пилотируемого аппарата, от действий которых зависят удачный взлёт, работа на орбите и посадка. И если в него закрадётся ошибка, последствия могут быть катастрофическими.
Именно так рассуждало руководство NASA, принимая решение о разработке компьютерной системы для проекта Space Transportation System, или, проще, Space Shuttle. И если с её аппаратной частью инженеры разобрались, создав дружную «пятёрку» компьютеров GPC, то с программами для них пришлось основательно повозиться. И не только затем, чтобы выловить все ошибки, но и для того, чтобы преодолеть стереотипы системных программистов, считающих, что они в точности знают, как правильно создавать софт для космического челнока.
Многочисленные успешные миссии Space Shuttle на практике доказали правильность выбранного в NASA подхода для создания одной из самых сложных программных систем авионики — PASS (Primary Avionic Software System).
Язык HAL/S. Высоким штилем о реальном времени
Приступая к проектированию программной системы Space Shuttle, руководство NASA имело возможность постоять на распутье, выбирая между уже имеющимися наработками, доказавшими свою состоятельность в пилотируемых полётах проекта Apollo, или разработкой с чистого листа.
Программированием компьютеров AGC (Apollo Guidance Computer) для лунных путешествий занималась лаборатория Дрепера, расположенная в Кембридже и относящаяся к Массачусетскому Технологическому Институту. Программная система компьютеров AGC разрабатывалась с использованием языка ассемблера. И эффективность этого подхода у специалистов не вызывала сомнений. С помощью ассемблерного кода можно виртуозно управлять вычислительным процессом, наиболее эффективно используя каждый байт памяти. Но у такой оптимизации имеется и обратная сторона: процесс разработки лабораторией Дрепера ассемблерных программ для проекта Apollo ни разу не уложился в отведённые сроки. А в случае обнаружения в уже разработанной программе ошибок её переработка превращалась в длительный процесс совместной работы инженеров NASA и программистов Дрепера, полный взаимных упрёков и препирательств.
И это при том, что миссии Apollo были сугубо специализированными. Проект же Space Shuttle предполагал создание многоцелевого космического аппарата, гибко подстраивающегося под текущие потребности NASA. Перепрограммирование компьютерной системы шаттла для каждой новой миссии должно быть быстрым, и язык ассемблера для такого случая был совершенно не пригоден. Именно поэтому руководитель отдела программирования NASA Ричард Партен принял решение использовать язык высокого уровня. Этим он навлёк на себя «праведный» гнев ортодоксальных системных программистов, искренне считающих, что никакая программа на высокоуровневом языке по скорости исполнения не сравнится с ассемблерным кодом. В пример приводились многочисленные соревнования ассемблера и популярного тогда языка FORTRAN, в которых последний выглядел явным аутсайдером.
Но Партен и не предлагал использовать FORTRAN. Его выбор пал на разработку выходцев из лаборатории Дрепера, в 1969 году основавших компанию Intermetrics Inc. Созданный ими язык высокого уровня назывался HAL/S и, благодаря поддержке векторной арифметики и возможности планирования программистом уровней приоритета модулей программы, идеально подходил для создания кода компьютеров GPC космического челнока.
По просьбе NASA специалисты Intermetrics включили в синтаксис HAL/S специальные операторы, делающие возможной разработку программ реального времени. Оператор SCHEDULE позволял точно определить частоту смены процессов в многозадачном режиме работы системы, операторы TERMINATE/CANCEL — антагонисты SCHEDULE занимались приостановкой и принудительным завершением процессов, а оператор WAIT обеспечивал их приостановку в случаях, когда операции ввода/вывода неоправданно затягивались.
Чтобы доказать правильность своего выбора, Партен решил организовать соревнования. Тестовая задача, выданная NASA лаборатории Дрепера и компании Intermetrics, должна была быть выполнена в строго отведённый срок и показать высокую производительность. Вот тут-то HAL/S и показал себя во всей красе. Решение на нём было готово задолго до отведённого «времени Ч», и при этом его производительность была всего на десять процентов ниже ассемблерного решения (которое, как обычно, было разработано с опозданием). Чуть позже, рассказывая о выборе HAL/S, Партен сказал: «Если бы мы тогда начали использовать ассемблер, то до сих пор бы торчали на Земле». Красноречиво, ничего не скажешь.
Вот так компьютеры шаттлов заговорили на HAL/S. Кстати, его название ничего общего с известным компьютером-психопатом из кларковско-кубриковской «Космической одиссеи 2001 года» не имеет. Эта аббревиатура означает всего-навсего Higher Avionic Language. Ну а литера "S" говорит о том, где язык применялся (Shuttle).
Концептуальная целостность. Разделяй и властвуй.
К середине 1973 года, выбрав язык разработки, в NASA определились с контрактами на создание PASS. Поскольку основной контракт на производство челноков был у компании Rockwell Corporation, последняя, естественно, посчитала, что будет создавать шаттлы, включая и программное обеспечение для них, единолично. Тем более что опыт разработки систем авионики для реактивных самолётов у Rockwell был немалый.
Но не тут-то было. Контракт на создание челночного софта NASA разделила между Rockwell и... IBM. Определённый резон в этом был: несмотря на то что, по предварительным оценкам, объём программного обеспечения для шаттлов был значительно меньше, чем для проекта Apollo, разнообразие программ и высочайшие требования к отказоустойчивости системы были таковы, что одной, пусть и опытной компании, справиться с задачей было не под силу. IBM предоставляла для проекта свои компьютеры AP-101, и уровень квалификации её программистов был нисколько не хуже уровня сотрудников Rockwell. Ещё одним немаловажным фактором, определившим выбор в пользу Голубого гиганта, была территориальная близость штаб-квартиры IBM и космического центра имени Джонсона. NASA, намучившись с проектом Apollo, программисты которого располагались в далёком Кембридже, посчитала, что разработчиков лучше иметь под боком.
Итак, 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? Уверен, что проверенный временем код этой программной системы авионики найдёт своё применение в будущих проектах пилотируемого освоения космического пространства.
К оглавлению