Разработка программного обеспечения для Apollo [закрыто]

Как разрабатывалось программное обеспечение во времена Аполлона?

Из различных источников можно узнать, что компьютер был IBM System 360, а язык был в основном диалектом фортрана или фортраном.

Я хотел бы знать, как они это сделали? Они просто написали или планировали? Были отзывы? Как тогда выглядели тестовые процедуры? Какой редактор использовали? Была ли внедрена система контроля версий? Как осуществлялось управление изменениями?

Извините, но это слишком широко. Вы можете начать с 43-страничного отчета по плану разработки и проверки программного обеспечения управления Аполлоном от 4 октября 1967 года. Затем продолжить с Компьютеры на борту космического корабля Аполлон: Компьютер управления Аполлон: Программное обеспечение на историческом веб-сайте НАСА.
Вы также можете прочитать о Маргарет Гамильтон , а также «Ее код привел людей на Луну — и сама изобрела программное обеспечение» и «Маргарет Гамильтон, инженер, который доставил Аполлон на Луну» . Поиск в Интернете чего-то вроде разработки программного обеспечения для Аполлона должен дать вам гораздо больше, чтобы начать работу.
Или, если вы предпочитаете, чтобы это было представлено в виде видео, вы можете просмотреть Moon Machines: The Navigation Computer . Это документальный фильм (продолжительностью около 43 минут), описывающий разработку навигационного компьютера Apollo, включая его программное обеспечение.
Да, слишком широко. О каком ПО вы говорите? На борту? Управление миссией? Симуляторы? Планирование полета?
@OrganicMarble Ты прав. Оглядываясь назад, я подозреваю, основываясь на упоминании System / 360, что OP в первую очередь не интересует бортовое программное обеспечение (которое также, вероятно, было разработано на чем-либо , кроме FORTRAN, в частности, из-за ограничений бортовых компьютеров). Я все еще думаю, что ссылки показывают, насколько широк вопрос - даже если они относятся только к некоторым компьютерным системам, которые сделали возможными миссии Аполлона, и, возможно, не к тому, что в первую очередь интересовало ОП.
@MichaelKjörling Я согласен со всем, что вы сказали и связали, я адресовал свой комментарий задавшему вопрос, чтобы объяснить, почему я проголосовал за закрытие.
Майк, вы могли бы начать с предоставления некоторых источников, которые вы упомянули. Это обеспечило бы некоторую специфичность, которая в настоящее время отсутствует.
@OrganicMarble О, я не спорил с тобой (на самом деле, как раз наоборот). Извините, если так попалось.
@JerardPuckett Я боюсь, что вопрос все равно будет слишком широким, даже со ссылками на утверждения, сделанные в самом вопросе. Это просто слишком многого требует. С другой стороны, сужение вопроса до одного из (по моим подсчетам, шести) аспектов, упомянутых в последнем абзаце, может, по моему мнению, сделать его достаточно узким, чтобы оправдать его повторное рассмотрение.

Ответы (1)

Исторический сайт НАСА дает ответы на многие ваши вопросы:

Я хотел бы знать, как они это сделали? Они просто написали или планировали? Были отзывы?

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

Даже в начале 1960-х цикл определения требований, проектирования, кодирования, тестирования и обслуживания продолжался...

Как тогда выглядели тестовые процедуры? Была ли внедрена система контроля версий? Как осуществлялось управление изменениями?

Три платы внесли непосредственный вклад в управление разработкой программного и аппаратного обеспечения Apollo. Совет по управлению конфигурацией космического корабля «Аполлон» отслеживал и оценивал изменения, запрошенные в конструкции и конструкции самого космического корабля, включая систему наведения и управления, частью которой был компьютер. Совет по контролю за изменениями процедур под председательством главного астронавта Дональда К. Слейтона проверил элементы, которые могли повлиять на дизайн пользовательских интерфейсов. Самым важным был Совет по контролю за конфигурацией программного обеспечения, созданный в 1967 году в ответ на продолжающиеся проблемы и возглавляемый в течение длительного периода Кристофером Крафтом. Он контролировал модификации, внесенные в бортовое программное обеспечение. Все изменения в существующей спецификации должны были проходить через эту плату для разрешения. Стэн Манн из НАСА прокомментировал, что Массачусетский технологический институт «

НАСА также разработало определенный набор контрольных точек, соответствующих циклу разработки программного обеспечения. ...

Дизайнеры разрабатывали программы с использованием компьютера Honeywell 1800, а затем IBM 36O, но никогда с реальным летным оборудованием. Компьютеры разработки генерировали двоичный объектный код и листинг. Лента [44], содержащая объектный код, должна быть протестирована и в конечном итоге выпущена для производства канатов с сердечником. Листинг служил документацией кода.

Для Apollo в Массачусетском технологическом институте был разработан специальный язык высшего порядка, который переводил программы в серию связей подпрограмм, которые интерпретировались во время выполнения. Это было медленнее, чем сопоставимая программа на ассемблере, но язык требовал меньше памяти для выполнения той же работы. В среднем для выполнения инструкции требовалось два машинных цикла — около 24 миллисекунд.

Любой нетривиальный софт требует дизайна. Никто не сидит за компьютером и просто начинает печатать, если хочет, чтобы это работало. Когда на карту поставлены человеческие жизни, используются более формальные процессы. Даже сегодня, когда я пишу сценарии оболочки, я «проектирую», пишу комментарии, которые описывают, что должно происходить по порядку. Иногда каждый комментарий представляет собой одну строчку кода, но чаще он становится подпрограммой… или полноценной подсистемой для нетривиальных проектов. Делать заметки на ходу очень важно, так как все мы теряем идеи во сне. Не ожидал, что Apollo сможет удовлетворить требования по мощности для IBM-360.
Разработка программного обеспечения для Apollo [закрыто]
СпросиСетьПолитика конфиденциальности1y, 0v