Цифровой журнал «Компьютерра» 2011 № 32 (80) - [3]

К оглавлению

Система 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, Партен сказал: «Если бы мы тогда начали использовать ассемблер, то до сих пор бы торчали на Земле». Красноречиво, ничего не скажешь.