От переводчика: В процессе чтения неплохого поста про американскую SLS (его тоже переведу, кстати) наткнулся на цитату из документа, на который часто ссылаются в постах про Space Shuttle, но целиком на русском я его найти не смог - особое мнение Ричарда Фейнмана в составе комиссии по расследованию катастрофы шаттла "Челленджер" в 1986 году.

Отчет ПРЕЗИДЕНТСКОЙ КОМИССИИ по катастрофе космического корабля “Челленджер”

Том 2: Приложение F - Личные наблюдения относительно надежности системы "Шаттл"
Р. П. Фейнман

Введение

Оценки вероятности катастрофического отказа системы с потерей корабля и человеческими жертвами странным образом варьируются от примерно 1/100 (оценки инженеров) до 1/100 000 (оценки менеджмента). Каковы причины и последствия такого рассогласования? Вероятность 1/100 000 означает, что каждый день в течение 300 лет можно запускать по шаттлу, и только один из них погибнет, так что правильнее было бы спросить: "В чем причина такой фантастической веры руководства в надежность системы?"

Мы также обнаружили, что критерии сертификации, используемые при проверках готовности к полету, постепенно становятся все менее строгими. Факт, что некоторая неисправность не привела к катастрофе в прошлом, часто принимается в качестве аргумента в пользу “безопасности” полетов с этой неисправностью, и очевидные проблемы проявляются снова и снова, часто вовсе без попыток их исправить или отложить полет.

Было использовано несколько источников информации:

  • Критерии для сертификации полетов, включая историю изменений в методике тестирования. Протоколы проверок готовности к полетам перед каждым запуском документируют все обсуждения и решения, связанные с безопасностью.

  • Из прямых показаний и отчетов ответственного за безопасность полигона Луиса Дж. Уллиана была получена информация об истории запусков твердотопливных ракет. В дальнейшем он (в качестве председателя комиссии по безопасности прерывания запуска, LASP) исследовал вероятность аварий, приводящих к радиоактивному заражению при запусках аппаратов с плутониевыми источниками питания (RTG, РИТЭГ) для будущих миссий, плюс аналогичное исследование НАСА.

  • Интервью с руководством и инженерами компании Marshall, а также неофициальные интервью с инженерами компании Rocketdyne для книги "История главных двигателей космических челноков".

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

  • Беседа с инженерами NASA JPL о надежности авионики (компьютеры, датчики и исполнительные механизмы).

  • Отчет "Обзор практик сертификации, потенциально применимых к пилотируемым многоразовым ракетным двигателям", подготовленный в Лаборатории реактивного движения Н. Муром и др. в феврале 1986 года для штаб-квартиры НАСА. В нем рассматриваются методы, используемые FAA и военными для сертификации газотурбинных и ракетных двигателей. Также получены неофициальные комментарии от авторов данного отчета.

Твердотопливные ускорители (ТТУ, SRB)

Оценка надежности твердотопливных ускорителей была сделана офицером по безопасности на полигоне на основе опыта предыдущих запусков. Из примерно 2 900 запусков 121 закончился неудачей (вероятность отказа 1/25). Надо учесть, однако, так называемые "детские болезни" - первые запуски новых моделей ракет, в которых обнаруживаются и исправляются конструктивные ошибки, так что более разумной цифрой для "зрелых" аппаратов может быть 1/50. При особом внимании к приемке деталей и сборке можно было бы достичь показателя немного ниже 1/100, но уровень 1/1000, вероятно, недостижим с сегодняшними технологиями. (Поскольку на "Шаттле" два ускорителя, эти показатели отказов необходимо удвоить, чтобы получить вероятность катастроф "Шаттла" из-за отказа ТТУ.)

Представители же НАСА утверждают, что эта цифра гораздо ниже. Они указывают, что эти цифры относятся к беспилотным ракетам, но, поскольку "Шаттл" является пилотируемым кораблем, "вероятность успеха миссии обязательно очень близка к 1,0". Не очень понятно, что означает эта фраза. Означает ли это, что она фактически близка к 1 или должна быть близка к 1? Далее они объясняют: "Исторически чрезвычайно высокая степень успеха миссий привела к различию в философии между программами пилотируемых космических полетов и беспилотными программами; то есть использование теоретической инженерной оценки вместо статистики тестирования". (Эти цитаты взяты из "Данные космических челноков для анализа безопасности РИТЭГов планетарных миссий", страницы 3-1, 3-2, 15 февраля 1985 г., НАСА, АО). Это правда: если бы вероятность отказа была всего лишь 1/100000, потребовалось бы непомерное количество тестов, чтобы определить эту цифру - в итоге получится лишь цепочка удачных полетов, из которой можно лишь понять, что вероятность меньше, чем единица на количество совершенных полетов. Но если реальная вероятность не так мала, эти полеты показали бы проблемы, могущие привести к сбоям, и даже фактические сбои - при вполне разумном количестве испытаний, так что стандартные статистические методы дали бы вполне разумную оценку. На самом деле, НАСА часто сталкивалось с такими близкими к аварийным ситуациями, и должно было бы понять, что вероятность катастрофы не так уж мала. Плюс, НАСА с одной стороны опирается на решение не определять надежность через прошлую статистику, как это делал офицер по безопасности, но в то же время апеллирует к истории, начиная "Исторически эта высокая степень успеха миссии…". Наконец, если мы заменяем статистическую вероятность инженерной оценкой, откуда берется такое огромное несоответствие между оценкой руководства и оценкой инженеров? Похоже, что и внутри организации, и для внешних отчетов руководство НАСА преувеличивает надежность своей системы до уровня фантастики.

Несостоятельность идеи принятия к полетам уплотнительных колец, которые показали эрозию и прогары в предыдущих полетах, в принципе понятна, и полет "Челленджера" - грустный пример. Эта идея опирается на историю предыдущих полетов; сертификация и успешное выполнение этих полетов воспринимается как доказательство безопасности… Но ведь эрозия и прогары не предусматривались при проектировании! Это - предупреждение о том, что что-то идёт не по плану: оборудование работает не так, как ожидалось, и эти неожиданные и непонятные процессы могут привести к любым последствиям, вплоть до катастрофических. Тот факт, что какой-то "сюрприз" не привел к катастрофе раньше, не гарантирует безопасности при следующем полете, по крайней мере до полного изучения процесса и его причин. Если при игре в русскую рулетку первый выстрел оказался осечкой - это не означает, что можно смело продолжать играть. Причина и последствия эрозии и прогаров не были изучены, при этом они происходили неодинаково в разных полетах и в разных кольцах; иногда больше, иногда меньше.

Несмотря на эти колебания от случая к случаю, чиновники вели себя так, как будто точно понимали, что происходит, приводя друг другу внешне логичные аргументы, часто основанные на "успехе" предыдущих полетов. Например, при определении безопасности полета рейса 51-L ("Челленджер") при наблюдаемой эрозии кольца в полете 51-C было замечено, что глубина эрозии составляла только одну треть его толщины, а эксперименты по оценке пределов прочности кольца показали, что необходимо было повредить его на всю толщину, чтобы кольцо разрушилось. Но вместо того, чтобы изучить процесс эрозии, или избавиться от неё вовсе, было решено, что существует "коэффициент безопасности, равный трем". Это странное использование инженерного термина "коэффициент безопасности". Если нужно построить мост, выдерживающий определенную нагрузку без деформации, трещин и изломов балок, можно спроектировать его на нагрузку в три раза больше. Этот "коэффициент безопасности" будет учитывать случайные превышения нагрузки при эксплуатации, неизвестные заранее дополнительные силы, слабые места в материале, неожиданные дефекты, и т.д. Если теперь на новый мост действует ожидаемая нагрузка, и в балке появляется трещина, это априори проблема. Никакого запаса прочности нет вовсе, хоть мост и не разрушился ("трещина прошла через балку только на треть"). Уплотнительные кольца ТТУ не были рассчитаны на эрозию; она - признак неизвестных проблем. Эрозия не может свидетельствовать о безопасности.

То есть, невозможно было быть уверенным в том, что в следующий раз эрозия не окажется втрое глубже, но тем не менее, чиновники НАСА убеждали себя и окружающих, что они понимают ситуацию, и она полностью под контролем, хоть показатели и варьируются от случая к случаю. Для расчета эрозии была составлена математическая модель, основанная не на физическом понимании, а на эмпирическом подборе параметров кривой. Предполагалось, что поток горячего газа набегает на материал уплотнительного кольца, и теплота определяется в точке застоя (с помощью термодинамических законов). Но для определения степени эрозии резины предполагалось, что она зависит только от этого нагрева по формуле, предложенной на основе данных по аналогичному материалу. График с логарифмической шкалой был похож на прямую, поэтому было предположено, что эрозия изменяется как 0.58 степень от температуры, причем этот коэффициент получен исключительно из реальных данных. Во всяком случае, было определено, что модель согласуется с эрозией (на глубину одной трети радиуса кольца) - но это же абсолютно неверно! Скорость потока газов - непредсказуема и зависит от структуры уплотнения, а кольцо может разрушиться даже при частичной или полном отсутствии эрозии. Известно, что эмпирическая формула была построена по облаку точек, некоторые из которых были в два раза выше, а некоторые - в два раза ниже установленной кривой, поэтому было решено, что максимальная эрозия с учетом всех неопределенностей может вдвое превышать расчетную, но это же абсолютно несостоятельное объяснение! При использовании математической модели необходимо уделять пристальное внимание любым неопределенностям в модели.

Жидкостный ракетный двигатель (ЖРД, SSME)

Во время полета 51-L все три главных двигателя космического челнока работали отлично, и лишь после аварии начали отключаться из-за прекращения подачи топлива. Однако возникает вопрос: если бы ЖРД серьезно отказал, и мы бы исследовали его так же подробно, как и ТТУ, обнаружили бы мы такое же недостаточное внимание к неисправностям и надежности? Другими словами, были ли организационные недостатки, способствовавшие аварии, присущи только производителю ТТУ, или они были более общей характеристикой НАСА? Для этого были исследованы основные двигатели и авионика орбитального самолета (аналогичные исследования его фюзеляжа или внешнего бака не проводились).

Жидкостный двигатель представляет собой гораздо более сложную конструкцию, чем ТТУ, поэтому обычный способ проектирования таких двигателей (для военных или гражданских самолетов) можно назвать компонентной системой, или проектированием "снизу вверх". Сначала необходимо тщательно разобраться в свойствах и ограничениях материалов, которые будут использоваться (например, для лопаток турбин), и для их определения начинаются испытания на экспериментальных установках; с учетом полученных данных проектируются и испытываются более крупные составные части. При обнаружении недостатков и ошибок проектирования они исправляются и перепроверяются в ходе дальнейшего тестирования. Поскольку за один раз тестируются только небольшие части системы, эти тесты и модификации не требуют чрезмерных затрат, но лишь потом можно приступить к окончательному проектированию всего двигателя в соответствии с необходимыми техническими условиями. К этому времени весьма вероятно, что двигатель в целом будет работать успешно, но и в случае отказов их легко изолировать и проанализировать, поскольку режимы работы, ограничения материалов и т.д. уже хорошо изучены. Скорее всего, модификации двигателя для исправления ошибок будут не очень сложными, поскольку большинство серьезных проблем уже обнаружено и устранено на более ранних, менее дорогостоящих этапах процесса.

С главным двигателем "Шаттлов" работали по-другому - можно сказать, "сверху вниз". Двигатель был спроектирован и собран сразу, с относительно небольшими предварительными исследованиями материалов и компонентов. То есть, когда обнаруживаются неполадки в подшипниках, лопатках турбины, трубопроводах охлаждающей жидкости и т.д., выявить причины и внести изменения становится дороже и сложнее. Например, были обнаружены трещины в лопастях турбины кислородного турбонасосного агрегата (кТНА). Вызваны ли они дефектами материала, влиянием кислородной атмосферы на свойства материала, тепловыми напряжениями при запуске или остановке, вибрацией и напряжениями при устойчивой работе, или в основном каким-то резонансом при определенных скоростях и т.д.? Сколько времени может пройти от зарождения трещины до ее разрушения, и как это зависит от уровня мощности? Использование готового двигателя в качестве испытательного стенда для решения таких вопросов чрезвычайно дорого: не хочется терять двигатель целиком, чтобы узнать, где и как происходит отказ оборудования. Тем не менее, эта информация необходима для получения уверенности в надежности двигателя в эксплуатации. Без точного понимания невозможно достичь уверенности. Еще одним недостатком метода "сверху вниз" является то, что даже если неисправность грамотно изучена, то даже простое по идее исправление, например, новая форма корпуса турбины, может оказаться невозможным без перепроектирования всего двигателя.

SSME - замечательное инженерное сооружение. У него большее соотношение тяги к весу, чем у любого другого двигателя на сегодняшний день, он проектировался на переднем крае техники, а порой и за ним, поэтому, логичным образом, возникло много разного рода недоработок и проблем. Поскольку, к сожалению, он был построен по принципу "сверху вниз", эти ошибки оказывается трудно найти и исправить. Проектная цель - срок службы в 55 миссий (27 тыс секунд работы либо в миссиях продолжительностью по 500 секунд, либо на испытательном стенде) - так и не была достигнута. В настоящее время двигатель требует очень частого технического обслуживания и замены важных деталей, таких как турбонасосы, подшипники, корпуса и т.д. Топливный ТНА требовал замены каждые три или четыре полета (хотя, возможно, сейчас это уже исправлено), а кислородный - каждые пять или шесть; это менее десяти процентов от первоначальной спецификации. Но наша главная забота здесь - определение надежности.

В общей сложности за примерно 250 тыс секунд работы в сумме двигатели довольно серьезно отказывали 16 раз. Инженеры уделяют пристальное внимание проявляющимся недостаткам и стараются устранить их как можно быстрее, для этого проводятся тесты на специальных установках, специально разработанных для каждого дефекта, тщательный осмотр двигателя на предмет наличия "подсказок" (например, трещин), а также теоретические исследования и анализ. Таким образом, несмотря на трудности проектирования "сверху вниз", благодаря упорной работе многие проблемы все же были решены.

Ниже приводятся некоторые известные проблемы ЖРД. Те, за которыми следует звездочка, похоже, были исправлены:

  • Трещины лопаток турбины в топливных ТНА *

  • Трещины лопаток турбины в кислородных ТНА

  • Разрыв линии зажигания (ASI) *

  • Неисправность продувочного обратного клапана *

  • Эрозия камеры ASI *

  • Растрескивание корпуса турбины топливного ТНА

  • Неисправность рубашки охлаждения топливного ТНА *

  • Неисправность выходного колена основной камеры сгорания *

  • Смещение сварного шва впускного колена главной камеры сгорания *

  • Подсинхронный вихрь кислородных ТНА *

  • Система безопасного отключения ускорения полета (частичный отказ в резервной системе) *

  • Скол подшипника (частично устранен)

  • Вибрация с частотой 4 000 герц, делающая некоторые двигатели неработоспособными

  • и т.д.

Многие из этих проблем являются "детскими болезнями" новой конструкции: 13 из них возникли в первые 125 тыс секунд работы двигателей и только три - во вторые 125 тыс. Естественно, никогда нельзя быть уверенным в том, что все ошибки устранены, и в некоторых случаях "исправление" может не устранить истинную причину. Можно предположить, что в течение следующих 250 тыс секунд может произойти как минимум один "сюрприз", т.е. вероятность 1/500 на двигатель за миссию. В миссии участвуют три двигателя, но допустим, что отказы будут локальными и затронут только один двигатель. "Шаттл" может вернуться на Землю с двумя двигателями, поэтому положим, что неизвестные "сюрпризы" даже сами по себе не снизят вероятность отказа главных двигателей ниже 1/500. К этому добавим вероятность аварии из-за известных, но еще не решенных проблем (те, что без звездочки в списке выше), об этом мы поговорим ниже. Напомним, инженеры компании Rocketdyne (производителя двигателей) оценивают общую вероятность как 1/10 000. Инженеры компании Marshall оценивают его как 1/300, в то время как руководство НАСА, которому эти инженеры подчиняются, утверждает, что он составляет 1/100 000. Независимый инженер, консультирующий НАСА, считал, что 1 или 2 на 100 - разумная оценка.

История процесса сертификации этих двигателей запутана и труднообъяснима. Первоначально подход, по-видимому, был такой: два образца двигателей должны были работать в два раза дольше нормативного времени без сбоев ("правило 2x"). По крайней мере, такова практика FAA (Агентство по сертификации авиатранспорта), и NASA, видимо, приняло ее, первоначально рассчитывая, что время работы составит 10 полетов (следовательно, нужно 20х полетного времени для сертификации). Очевидно, что для сравнения лучше всего использовать двигатели с наибольшей общей (летной плюс испытательной) наработкой - так называемые "лидеры парка". Но что, если какой-то образец выйдет из строя быстрее? Тогда, учитывая "правило 2x", мы должны признать двигатели способными отработать половину стендового времени самого плохого образца.

Медленное движение в сторону уменьшения коэффициента безопасности можно проиллюстрировать на примере лопаток турбины топливного ТНА. Прежде всего, была отброшена идея тестирования всего двигателя: у каждого экземпляра двигателя было много важных частей (например, самих турбонасосов), заменяемых через частые промежутки времени, так что "правило 2х" должно быть перенесено с двигателей на их компоненты. Мы принимаем тТНА для сертификации, если два образца успешно отработали каждый в течение вдвое большего времени (и с практической точки зрения больше не настаиваем, чтобы это было 10 миссий). Но что значит "успешно"? FAA считает трещину на лопатке турбины "отказом", таким образом действительно обеспечивая коэффициент безопасности больше 2 на практике. Двигатель может нормально работать в течение некоторого времени с момента появления трещины и до момента, когда она станет достаточно большой для разрушения лопатки. FAA рассматривает новые правила, учитывающие это дополнительное время, но только при условии, что процесс тщательнейшим образом проанализирован с помощью проверенных моделей, и с использованием материалов, прошедших тщательные испытания. Ни одно из этих условий не применимо к главному двигателю "Шаттлов".

На многих лопатках турбины ТНА были обнаружены трещины. В одном двигателе - три штуки было обнаружено после 1900 секунд работы, в другом - ни одной через 4200 секунд, хотя в среднем на таких "пробегах" уже обнаруживались трещины. Надо пояснить, что напряжение в материале лопаток в основном зависит от уровня мощности двигателя. Полет "Челленджера" должен был проходить на уровне мощности 104% от номинала, и предыдущие полеты проходили на этом уровне в течение большей доли времени работы двигателей. Судя по некоторым публикациям, при уровне 104% от номинальной мощности время до появления трещин примерно в два раза больше, чем при 109% или "уровне полной мощности" (FPL). Более поздние полеты планировались на 109% из-за более тяжелой полезной нагрузки, и многие испытания проводились на этом уровне, поэтому, разделив время при 104% на 2, мы получим т.н. время эквивалента полной мощности (EFPL). (Очевидно, что при этом вводится некоторая неопределенность, но она специально не изучалась); самые "ранние" трещины были обнаружены при 1 375 EFPL.

Теперь правило сертификации звучит как: "Ограничить все лопатки максимум 1 375 секундами EFPL". Если кто-то возразит, что коэффициент безопасности 2х тут теряется, то можно указать, что одна турбина проработала 3800 секунд EFPL без трещин, а половина этого времени - 1900, так что мы тут даже консервативны. В реальности же, тут совершаются три грубейшие ошибки. Во-первых, у нас есть только один "долгожитель", и он не является "лидером парка", а два других образца после 3 800 или более секунд работы имели 17 треснувших лопаток "на двоих" (в каждом двигателе 59 лопаток). Во-вторых, мы отказались от "правила 2x" и почему-то заменили его 1х. И в-третьих, 1 375 - это "пробег", на котором мы увидели трещину. Мы можем сказать, что до 1 375 секунд трещин не было обнаружено, но на самом деле последний раз мы проверяли лопатки (и не видели трещин) на 1 100 секундах EFPL. Мы не знаем, когда точно образовалась трещина между этими моментами: например, трещины могли образоваться при 1 150 секундах EFPL. Кстати, "Челленджер" должен был запустить двигатель, очень близкий к этому пределу прочности, в процессе завершения полета.

Наконец, утверждается, что система безопасна, даже если отказаться от принятого FAA условия полного отсутствия трещин, и считать "отказом" только полностью разрушенную лопатку - при таком определении вообще ни один двигатель еще не "вышел из строя". Идея тут в том, что у нас есть достаточно времени между появлением трещины и разрушением лопатки, и мы можем "просто" проверять все лопатки на наличие трещин между миссиями. Если нашли - заменяем, а если нет - у нас будет достаточный запас времени для безопасной миссии. Таким образом, мы "перемаркируем" проблему трещин из проблем безопасности полетов во всего лишь проблему технического обслуживания.

Возможно, это действительно так. Но действительно ли мы уверены, что трещины всегда растут достаточно медленно, чтобы за время миссии не произошло разрушения? Три двигателя работали в течение длительного времени с несколькими треснувшими лопатками (около 3000 секунд EFPL), при этом лопатки не отламывались, но где гарантия, что другие двигатели поведут себя так же?

Очень похожая история фигурирует в сертификации окислительного ТНА, но мы не будем здесь в неё углубляться. В целом, очевидно, что обзоры готовности к полетам и правила сертификации наглядно показывают проблемы с главными двигателями челноков, аналогичные проблемам с ТТУ.

Авионика

Под "авионикой" подразумевается вся компьютерная система орбитального корабля, а также ее входные датчики и выходные исполнительные механизмы. Тут мы ограничимся собственно компьютерами и не будем интересоваться надежностью входной информации от датчиков температуры, давления и т.д., а также тем, точно ли за выводом компьютера следят исполнительные механизмы запуска двигателей, механические органы управления, дисплеи для астронавтов и т.д.

Компьютерная система "Шаттла" очень сложна, она содержит более 250 000 строк кода (ха-ха, прим перев). Она отвечает, среди прочего, за автоматическое управление подъемом на орбиту целиком и за спуск от момента нажатия кнопки, выбирающей место посадки, и до входа в плотные слои атмосферы (со скоростью ниже звуковой). Можно было бы выполнить всю посадку автоматически (разве что сигнал опускания шасси не контролируется компьютером и должен подаваться пилотом, якобы из соображений безопасности), но такая полностью автоматическая посадка, вероятно, не так безопасна, как посадка под управлением пилота. Во время орбитального полета компьютер используется для управления полезной нагрузкой, отображения информации для космонавтов и обмена информацией с Землей. Очевидно, что безопасность полетов требует гарантий точности работы этой сложной системы: как самих компьютеров, так и программного обеспечения.

Надежность оборудования обеспечивается за счет четырех идентичных независимых вычислителей. Там, где это возможно, у каждого датчика также есть несколько копий (обычно тоже четыре), и каждая копия отправляет данные во все четыре компьютера. Если входные данные от датчиков расходятся, в качестве эффективного входа используются усредненное значение или "выбор большинства" (в зависимости от ситуации). Все компьютеры работают с идентичными копиями программы, и их входные данные тоже одинаковы (т.к. каждый компьютер видит все копии датчиков), поэтому на каждом этапе работы программы результаты на всех компьютерах тоже должны быть идентичными. Время от времени их сравнивают, но так как процессоры могут работать на немного разных скоростях, перед каждым сравнением состояние синхронизируется. Если один из компьютеров не согласен с остальными или слишком поздно подготовил свой ответ, три других считаются "правильными", а "ошибочный" - полностью исключается из системы. Если теперь другой компьютер выйдет из строя (это определяется двумя оставшимися), он удаляется из системы, а полет прерывается, и начинается снижение к месту посадки. Очевидно, это избыточная система, поскольку отказ одного компьютера никак не влияет на выполнение миссии. Плюс, в качестве дополнительной функции безопасности, имеется отдельный пятый компьютер, в память которого загружены только программы подъема и спуска, и который способен управлять спуском, если произойдет отказ более двух из четырех основных машин.

К сожалению, в памяти главного компьютера не хватает места для всех программ подъема, спуска и полезной нагрузки в полете, поэтому память загружается астронавтами вручную с лент, четыре раза за полет. Из-за огромной сложности замены программного обеспечения такой системы, а также для обеспечения совместимости исправлений, аппаратное обеспечение не менялось с момента создания системы (около пятнадцати лет назад). Фактически, это оборудование устарело; например, память используется старого типа, с ферритовым сердечником. Становится все труднее найти производителей, которые бы надежно поставляли такие устаревшие компьютеры; современные компьютеры намного надежнее, быстрее, и не требуют ручной перезагрузки памяти.

В процессе разработки программное обеспечение проверяется очень тщательно по принципу "снизу вверх". Сначала проверяется каждая новая строка кода, затем проверяются участки кода или модули. Объем проверок увеличивается шаг за шагом, вплоть до интеграционного тестирования изменений в составе системы целиком - результат считается новой версией ПО. Но совершенно независимо существует независимая группа верификации, которая занимает позицию "противника" по отношению к группе разработки и проверяет ПО, как если бы она была потребителем поставляемого продукта. Также перед отправкой на челнок, новое ПО активно используется в симуляторах полетов. Обнаружение ошибки во время интеграционного тестирования считается серьезной проблемой, и ее причины тщательно изучаются, чтобы избежать подобных ошибок в будущем. Такие ошибки были обнаружены только около шести раз за все время разработки и доработки программ (в т.ч. для новых полезных нагрузок). Основной принцип тут: все проверки не показывают уровень безопасности программы, а только подтверждают этот уровень, в безопасных для людей условиях. О безопасности полетов следует судить исключительно по тому, насколько хорошо программы проходят проверочные испытания.

Можно смело сказать, что система проверки компьютерного программного обеспечения и отношение к ней - самого высокого качества. По-видимому, сюда не добралась атмосфера самообмана и плавного снижения стандартов, характерная для оценки безопасности главных двигателей и ТТУ "Шаттла". Стоит заметить, что недавно руководство компании предложило урезать такие сложные и дорогостоящие тесты как ненужные на поздних этапах программы "Шаттлов". Этому нужно сопротивляться, поскольку необходимо держать под контролем взаимодействие частей системы и ошибки, порождаемые порой небольшими изменениями в совершенно других блоках. Да, в отдел разработки постоянно поступают запросы на новые изменения для поддержки новых полезных нагрузок, новых требований и модификаций, эти изменения стоят дорого, потому что они требуют тщательного тестирования. Но правильный способ сэкономить тут деньги - сократить количество вносимых изменений, а не качество тестирования каждого из них.

Можно добавить, что эта система может быть значительно улучшена с помощью более современного оборудования и методов программирования. Любой конкурент вне NASA может начать все сначала и учесть все "подводные камни", выявленные в процессе работы над системой, и потенциально такой же подход может оказаться хорошей идеей и для NASA, но этот вопрос требует тщательной многосторонней оценки.

Наконец, вернемся к датчикам и исполнительным механизмам системы авионики. Отношение к отказам и надежности системы здесь не так хорошо, как у разработчиков ПО: например, было обнаружено, что некоторые датчики температуры иногда выходят из строя. Однако те же датчики продолжали использоваться через полтора года после диагностики неисправности, и один запуск даже пришлось отменить из-за одновременного отказа двух из них. Но и после этого эти ненадежные датчики продолжали использоваться снова и снова. Также, реактивные двигатели малой тяги (RCS), используемые для управления в полете, все еще недостаточно надежны. В системе RCS есть значительная степень резервирования, но довольно долго в ней происходят различные сбои, хотя ни один из них еще не был достаточно масштабным, чтобы серьезно повлиять на программу полета; работа двигателей проверяется датчиками, и в случае сбоя компьютеры активируют соседний двигатель. Но эти двигатели вообще не должны отказывать, так что эта проблема все еще требует адекватного решения.

Выводы

Консервативные критерии сертификации позволяют гарантировать высокую безопасность полётов, но в то же время негативно влияют на график запусков и программы в целом. Вследствие этого с помощью, на первый взгляд, логичных аргументов эти критерии плавно изменяются так, чтобы полеты все еще могли быть сертифицированы в срок, но в результате полеты совершаются в относительно небезопасной конфигурации, с вероятностью отказа порядка 1 процента (трудно сказать точнее).

Официальное руководство, с другой стороны, утверждает, что вероятность катастрофы в тысячу раз меньше. Возможно, за этим стоит желание заверить правительство в успехе NASA, чтобы гарантировать дальнейшее финансирование; либо руководство искренне верит в эти цифры, демонстрируя почти невероятное отсутствие коммуникаций между менеджерами и инженерами.

В любом случае, было огромной ошибкой побудить непрофессионалов (имеется в виду прежде всего победительница конкурса "Учитель в космосе" и член экипажа "Челленджера" Криста МакОлифф - прим. перев.) лететь на такой опасной машине, как если бы она достигла уровня безопасности обычного авиалайнера. Астронавты, как и летчики-испытатели, трезво оценивают свой риск, и мы чтим их мужество. Похоже, Криста МакОлифф была также человеком большого мужества, и она была гораздо ближе к пониманию истинной степени риска, чем руководство НАСА хотело бы заставить нас поверить.

Нужно убедиться, что официальные лица НАСА не оторваны от реальности, достаточно хорошо понимают технологические недостатки и активно пытаются их устранить. Они должны трезво сравнивать стоимость и полезность "Шаттла" с другими способами выхода в космос, и максимально реалистично подходить к заключению контрактов, оценке затрат и сложности проектов. Следует рассматривать только реалистичные расписания полетов, которые имеют разумные шансы быть выполненными без компромиссов с безопасностью. Если в такой ситуации правительство их не поддержит - пусть. НАСА обязано быть откровенным, честным и информативным перед гражданами, у которых оно просит поддержки, чтобы эти граждане могли принимать мудрые решения по использованию своих ограниченных ресурсов.

Для успеха технологии реальность намного важнее пиара, ведь природу не обманешь.

P.S. От переводчика: Шаттл “Колумбия” потерпел крушение 1 февраля 2003 года (полёт № STS-107) при входе в атмосферу Земли перед посадкой, через 17 лет после “Челленджера”. После этого программа Space Shuttle была постепенно свёрнута.

Комментарии (77)


  1. Shatun
    21.09.2021 18:11
    +30

    Если интересны детали, то это история очень хороша описана во второй части автобиографии Фейнмана("Какое тебе дело до того, что думают другие?").

    Кто нечитал - очень рекомендую, замечательные книги(первая-"Вы, конечно, шутите, мистер Фейнман!")


    1. Legomegger
      21.09.2021 19:08
      +21

      "Вы, конечно, шутите, мистер Фейнман!" это лучшее что я читал, в ней есть все: юмор, жизненные уроки, мотивация и биография одного из самых интересных и умных людей 20го века


      1. Ergistael
        22.09.2021 12:01
        +3

        Безусловно, прекрасная книга и, собственно, личность выдающегося ученого.

        Но вот мне из трех жизнеописаний великих физиков (вторая - про Л.Д. Ландау) более всего мне импонирует личность и биография Роберта Вуда. Субъективно, Фейнман постоянно старается выглядеть простаком. Вуд более непритворный. Ну а Ландау - это Ландау.

        Здесь вкратце, в Сети полнее: https://elementy.ru/nauchno-populyarnaya_biblioteka/435110/Robert_Uilyams_Vud


        1. Ag47
          22.09.2021 12:53

          А какую книгу про Ландау посоветуете?


          1. Ergistael
            22.09.2021 13:00
            +2

            К сожалению, не вспомню, но, кажется, я читал "Воспоминания о Л. Д. Ландау" коллег и друзей, автор: И.М. Халатников. Хорошо, что разные мнения с разных сторон. Человек он был сложный.


        1. mkostya
          23.09.2021 11:53

          Роберт Вуд — замечательная книга. Перечитывал несколько раз.


    1. ilvar Автор
      21.09.2021 19:08
      +4

      Да, книги тоже отличные. Мне из первой запомнилась история, как он преподавал в Бразилии, не зная португальского - очень похоже на мой опыт в Латине без испанского.


    1. wkia
      21.09.2021 19:30
      +4

      Фейнман - безусловно умный человек, один из умнейших своего времени. Однако, я помню с каким удовольствием сел читать "Вы, конечно, шутите...", и в каком шоке я был по окончании прочтения. Я не знаю, каким человеком он был на самом деле, но в книге он показан "многогранной неординарной личностью" без каких либо признаков эмпатии. Если это правда, то это просто страшно, находиться рядом стаким человеком. Хотя, возможно, гениям многое прощают.


      1. ilvar Автор
        21.09.2021 20:08
        +3

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


      1. victor_1212
        21.09.2021 21:05
        +2

        >по книжке "Вы, конечно, шутите..." трудно судить о человеке, насколько знаю он вполне адекватный был, конечно не без причуд, почитайте более-менее полную биографию к примеру, может измените мнение

        ps

        когда его попросили этой катастрофой заняться, он уже больной был, типа знал что немного осталось, на обезболивающих лекарствах находился, но таки сделал что мог, без него вероятно не нашли бы причину так быстро, просто к сведению о человеческих качествах


        1. ilvar Автор
          22.09.2021 11:10
          +2

          Не сказал бы, что ему за это были сильно благодарны: его выводы вовсе не хотели включать в отчет, и согласились на "особое мнение" (которое официально не обязательно принимать во внимание) только после того, как он пригрозил со скандалом выйти из комиссии.


          1. victor_1212
            22.09.2021 17:10

            >Не сказал бы, что ему за это были сильно благодарны

            еще бы, типа один против большинства, не могли поверить пока не показал публично что делается с уплотнением при достаточном охлаждении, но не в этом дело, по большому счету именно он предложил наиболее реальную версию, это позволило быстро усилить уплотнение и продолжить полеты,

            конечно и этим в том числе он в памяти остался, вообще его работы по физике очень сильные были, стоит взглянуть, если интересуетесь, ну а про его лекции по физике типа все знают, у меня до сих пор на полке

            ps

            вообще довольно интересный site, откуда оригинал пришел, там много чего стоит посмотреть


            1. ilvar Автор
              22.09.2021 20:12

              Проблема в том, что проблема-то была не в уплотнении :) про это в следующем посте еще будет.


              1. victor_1212
                22.09.2021 20:42

                >Проблема в том, что проблема-то была не в уплотнении :)

                Серьезно? Ну ждем сенсации :)


      1. BigBeaver
        21.09.2021 22:25
        +4

        Очень странные у вас выводы. Почитайте второй том — про отношения с женой и тд.


      1. bbs12
        22.09.2021 14:21
        +1

        Шредингер в 40 лет вообще жил с 14 летней девочкой и ничего.


        1. astenix
          22.09.2021 15:06
          +6

          Или не жил.


          1. bbs12
            22.09.2021 15:42
            +1

            Или не с девочкой. Возьмём атом находящийся в суперпозиции, к которому подключён аппарат для изменения пола, а к этому аппарату подключена девочка...


            1. drWhy
              22.09.2021 16:29
              +1

              «Мышка за кошку,
              Кошка за Жучку,
              Жучка за внучку...»


      1. wadeg
        23.09.2021 01:42
        +1

        Я не знаю, каким человеком он был на самом деле, но в книге он показан «многогранной неординарной личностью» без каких либо признаков эмпатии.
        Неожиданный вывод, вообще не соответствующий тому, что я там прочел. А на чем такой вывод основан, не развернете? Честно, очень интересно.


    1. nikolay_karelin
      22.09.2021 22:57
      +1

      В этой книге есть и "Особое мнение", так что перевод уже был ;)


      1. ilvar Автор
        22.09.2021 23:02

        В сети этого материала не нашел. В любом случае, чтиво занимательное.


  1. Goodwinnew
    21.09.2021 18:20
    +14

    >Факт, что некоторая неисправность не привела к катастрофе в прошлом, часто принимается в качестве аргумента в пользу “безопасности” полетов с этой неисправностью, и очевидные проблемы проявляются снова и снова, часто вовсе без попыток их исправить или отложить полет.

    Именно - это аналог "я столько раз заходил в сарай с сеном с горящей сигаретой и пожара не было".

    Это логика менеджеров. У них же нет инженерного образования - вот они и принимают решения на основе своей логики.

    Сложный вопрос, как построить управление проектом так, что бы в ключевых точках (безопасность например) окончательное решение было за инженерами, а не за менеджерами.


    1. Alexey2005
      21.09.2021 18:57
      +4

      Никак, потому что строить управление тоже будут менеджеры, а не инженеры.


    1. ilvar Автор
      21.09.2021 19:09
      +14

      Справедливости ради, инженеры тоже таким страдают частенько. Может, не очень хорошие инженеры, но все же. Работает - не трогай!


      1. byme
        21.09.2021 19:34

        Работает - не трогай!

        Это все таки другое. Оно работает в этом случаи это:
        - ничего не поломано
        - нет предпосылок к тому что что-то сломается

        Да не понятно как это работает, но оно работает поэтому лучше не трогать


        1. ilvar Автор
          21.09.2021 20:15
          +16

          Но если мы не понимаем более-менее точно, как работает - откуда можем быть уверены, что работает не на пределе возможностей и завтра не сломается? Те же трещины, описанные Фейнманом - можно, как оказалось, рассматривать не как угрозу безопасности, а как просто дополнительный пункт в протоколах обслуживания. Если мы не изучили досконально свойства материала при сверхнизких температурах в атмосфере кислорода - мы не знаем точно, как там распространяются трещины. Проблема не в том, что "на самом деле" они опаснее или безопаснее, чем решило НАСА; проблема в том, что это решение было принято гораздо более "от балды", чем следовало бы.


          1. Mausglov
            21.09.2021 23:58
            +1

            думаю, что "не трогай" всё же следует понимать как "не вмешивайся бездумно".
            Для примера возьмём те же лопатки. Допустим, есть другой сплав, который в среднем меньше трескается, чем текущий. Если бездумно начать изготавливать лопатки из нового сплава, то в голову приходят следующие проблемы:
            1) именно эта причина возникновения трещин разрушает новый сплав быстрее, чем старый;
            2) новый сплав быстрее корродирует от топлива.
            Да вообще, любое воздействие, которое на старый сплав не влияло. "Ошибка выжившего".


            1. ilvar Автор
              22.09.2021 11:16
              +1

              И "ошибка выжившего", и прочие когнитивные искажения, да. Многие из них основаны на том, что человеку комфортнее работать с тем, что он видит и знает. У нас в команде как-то раз было "давайте возьмем тул Х, потому что его команда лучше знает" - вроде бы логично, но через несколько месяцев все инженеры, которые знают Х - по очереди ушли, а для остальных "внезапно" порог входа, про который никто не подумал при выборе, оказался высоковат. Bus factor практически в чистом виде.


      1. sa1ntik
        28.09.2021 20:49

        Работает - не трогай!

        Этот принцип вовсе не про то, что вы писали. Он именно про отсутствие необходимости бездумных изменений в то, что уже и так работает и его работа всех устраивает.

        Допустим, у вас есть программа, которая выполняется за 10 000 тактов процессора. Эта скорость работы всех устраивает, стабильность работы выше всяких похвал и нареканий по существу вообще нет. Приходит человек с горящими глазами, говорит "я знаю как сделать так, чтобы она начала работать за 9 000 тактов!", его никто не останавливает и тут возможны два варианта:

        1) Оно действительно начинает не менее стабильно работать за 9000 тактов.

        2) Оно не работает/работает не всегда и вываливается/при определенных ситуациях работает за 90 000 тактов. В итоге проблемы с другими программами, всё встало и судорожно начинают чинить.

        Принцип "работает - не трогай" как раз отсекает подобные ситуации рискОвых изменений в гарантировано работающие системы ради извлечения никому не нужной выгоды. То есть в конечном итоге предотвращают работу ради работы с риском уложить всё.

        Это я вам как инженер говорю.

        P.s. Наиболее вероятно вы возразите что "возможно существуют ситуации в которых сломается и старая программа" и действительно такие ситуации возможны. Проблема в том, что проводя ненужные изменения мы увеличиваем риски возникновения таких ситуаций, а не уменьшаем. Так как старая программа к этому моменту проверена во всех уже случавшихся сценариях использования, а новая это пока непаханое поле из граблей.


        1. ilvar Автор
          28.09.2021 23:01

          При этом в существующей программе есть known knowns (известные ограничения и архитектурные решения), known unknowns (техдолг и известные баги) и unknown unknowns (неизвестные баги), и сумма у них всегда 1.0. Т.е. если наш инженер подходит к этой легаси системе, и у него KK и KU около нуля ("бездумный подход"), то UU (ака поле из граблей) окажется очень большим. В реальности часто ситуация ухудшается тем, что человеку кажется, что он "в принципе" все понимает, но на самом деле нет.

          Идеальная ситуация для рефакторинга же - когда KU довольно большое, но и KK тоже. Это позволяет трезво оценить и overhead (который рефакторинг помогает снизить), и риски. Другое дело, что неэффективное легаси редко когда бывает отлично задокументировано, включая процесс принятия решений и рассмотренные варианты.

          Плюс недостаток полномочий, плюс субординация, плюс политика. Результат вполне можно обозвать той же фразой "работает - не трогай", только значение у неё гораздо менее позитивное выходит.


          1. sa1ntik
            29.09.2021 07:59

            Программа в данном случае лишь аналогия.

            Инженеры всё же обычно чуть другим занимаются и в их случае, даже если рассматривать крайне близкую к "гражданскому" программированию промышленную автоматику, KK и KU сами по себе не столь большие. Вернее в большинстве случаев KU ~ 0 так как установка функционирует, функционирует безостановочно (не считая выводы на ППР и прочее обслуживание) и никому не мешает, долгов не создаёт. KK тоже ~ 0 так как существенным ограничением может быть, разве что, невозможность интеграции установки. Или нехватка входов/выходов для модернизации.

            Поэтому UU там всегда стремится к единице. Исходя из этой причины и не занимаются в промышленности обновлением ради обновлений (кроме некоторых ещё не наученных горьким опытом).

            Плюс в данном случае есть огромная проблема с тестированием. Так как симуляторы хоть и есть, но без полноценного "виртуального двойника" они бессмысленны. Поэтому наладка ПО, в случае промышленной автоматики, всегда идёт на кошках. А это ещё и время простоя.

            Поэтому применительно к инженерным системам "работает - не трогай" это скорее сродни "не трогай оголённые провода". То есть свод правил, соблюдая которые, ты не подвергаешь риску себя и окружающих.


            1. ilvar Автор
              29.09.2021 22:58
              +1

              KK это вообще все ограничения в работе установки, они всегда есть. Требования к питанию, к сырью, к управляющим сигналам.

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


              1. sa1ntik
                30.09.2021 12:10

                Требования к питанию, к сырью, к управляющим сигналам

                Новое питание не подвезут - ГОСТы, смена сырья ведёт или к смене установки, или к её глубокой модернизации (если она не рассчитана на новое сырьё), управляющие сигналы уже и так есть. Поэтому нет, это не считово.

                С другой стороны - вот например, исследования уплотнительных колец во всяких интересных условиях не проводились, потому что ну вот система летает, все в порядке с ними там. 

                Мы говорим о несколько разных вещах. Для ракеты эти условия являлись нормальными условиями эксплуатации (или были ошибочно включены в них) поэтому нет, она всё же не была нормально проверена. У установки, которая работает вот уже десять лет при нормальных условиях эксплуатации баги уже не всплывают. А если ей подали другое напряжение/оно кончилось/запихали не то и не туда - условия перестают быть нормальными.


                1. ilvar Автор
                  30.09.2021 19:33
                  +1

                  Так вся статья про то, что "нормально проверено" для разных людей с разным опытом может означать разные вещи. Для кого-то - работа на стенде двукратное время, для кого-то - год реальной эксплуатации экспериментальной установки, для кого-то вот "ну, мы уже 50 раз челноки запускаем, и пока ни разу не бабахнуло".

                  Так же и между "работает с большим запасом прочности", "работает на пределе возможностей" и "ведет себя странно, но почему-то до сих пор не сломалось" есть некоторая разница в разрезе "не трогай". Причем, в последнем случае "не трогай" даже чаще встречается, потому что любое вмешательство может вывести систему из этого хрупкого равновесия, да и ответ на вопрос "так, кто последний систему трогал?" инициатора изменений явно не обрадует, даже если проблема вызвана не ими.


                  1. sa1ntik
                    01.10.2021 07:13

                    Так вся статья про то, что "нормально проверено" для разных людей с разным опытом может означать разные вещи.

                    Мы с вами про промышленность. Установки работает в круглосуточном или окологрулосуточном режиме.

                    То есть время, сравнимое с полётами всей программы Шаттл (имеется ввиду активная фаза работы ускорителей) они пройдут меньше, чем за месяц.

                    "работает на пределе возможностей"

                    Для подавляющего большинства промышленных установок, особенно электрических, это диагностируется очень просто и с высокой степенью достоверности.


                    1. ilvar Автор
                      01.10.2021 20:32
                      +1

                      Для установки, которая работает круглосуточно, и требования к наработке на отказ несколько повыше, чем к SSME.

                      Похоже, вы имеете в виду "установки" в довольно узком смысле. Я же - всё, от розетки у меня дома и до пресловутых SSME.


                      1. sa1ntik
                        05.10.2021 07:56

                        Похоже, вы имеете в виду "установки" в довольно узком смысле.

                        Ну вообще я про промышленность, а "работает - не трогай" применяется обычно инженерами (обычно по эксплуатации) именно там. И даже несколько раз уточнил.

                        Если мы говорим про "вообще всё" то помимо всех возможных рисков уронить что-то в момент его трогания, надо оценивать и последствия от его потрогивания.


    1. fougasse
      21.09.2021 19:31
      +2

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

      Ключевые окончательные решения от инженеров ничего не гарантируют.


      1. ilvar Автор
        21.09.2021 20:19
        +11

        Есть еще такая особенность, инженеры склонны преуменьшать важность не-функциональных требований: сроки, стоимость, вот это все. Поэтому в проекте нужен человек (один), который выслушает все заинтересованные стороны и примет решение. Как Королев, Фон Браун или вот сейчас Маск у себя - даже такой фрик, похоже, лучше, чем групповое принятие решений.


        1. Knkplua
          21.09.2021 21:13
          +2

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


          1. Goupil
            21.09.2021 21:31
            +11

            Предыдущий комментатор это и имел ввиду. Недаром существует понятие design by committee.

            "Успехи" Боинга, где такого центрального человека нет, и успехи SpaceX где такой человек, пускай и эксцентричный, есть - тому пример.


          1. hoegni
            22.09.2021 16:32
            +1

            Это обычно так. А если еще группа - это представители разных коллективов, и каждый со своими интересами, то всё - туши свет... А в больших проектах это обычно так. В результате и получаются чудовищные компромиссные монстры.


            1. ilvar Автор
              22.09.2021 20:14

              А потом "предполагаемый противник" узнает от разведки про новую технологию, приписывает ей фантастические возможности и создает ещё более монструозную систему, ага.


          1. sa1ntik
            28.09.2021 20:59

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

            Групповое принятие решений, как показывает моя личная практика, всегда хуже индивидуального. По одной простой причине: ответственность.

            В случае, если решение принимается индивидуально, сказать "так я тут не виноват, меня вообще подговорили и Федька так сказал" хоть и получится, но будет звучать максимально глупо. При принятии решения человек (если он, конечно, осознаёт важность своего решения и его последствия) будет более скрупулезно взвешивать все "за" и "против".

            В случае группового принятия решений, ответственность за них размазывается по группе лиц. Персональная ответственность отсутствует как факт, а срабатывающие механизмы самоуспокоения твердят под нос "Да Федька там громче всех кричал и бил себя пяткой в грудь что все ОК будет". А при больших размерах группы какие бы то ни было мысли об ответсвенности за это решение отсутствуют: "Проголосую как большинство решит, а сам разбираться не буду".

            Поэтому нет, ответственный должен быть только один. Что за выполнение задачи, что за принятие решений.


            1. ilvar Автор
              28.09.2021 23:13

              "Хуже-лучше" это одно измерение, в реальности же их несколько. Например, при принятии решений в одно лицо оказывается гораздо проще облажаться с документированием этого процесса - если не целиком забить, то уж пропустить "неважные" части внутреннего диалога вообще обычное дело. А в итоге бам! bus factor == 1


        1. tzlom
          22.09.2021 09:58
          +1

          С другой стороны Н1 так и не полетела и виноват в этом тоже Королев. По хорошему принятие решений должно быть отделено от их выработки, но найти такого человека очень сложно - обычно у него или не будет компетенций и тогда решение будет базироваться на симпатиях и чуйке или же у него будет собственное мнение и тогда любые аргументы могут быть отвергнуты и снова в деле чутьё а не логика. Интересно как у Маска с этим обстоят дела.


          1. drWhy
            22.09.2021 10:11
            +1

            Виноват тем что не пустил «вонючие» топлива в пилотируемую космонавтику?


            1. Brenwen
              22.09.2021 10:28
              +2

              Не вонючие даже, а канцерогенные и мутагенные. А в том, что Н1 не полетела, виноват Глушко, зарывший уже готовые модернизированные ракеты с двигателями НК-33 в степи, так как если бы они слетали успешно - никто бы ему не дал бюджет на Энергию.


          1. sshikov
            22.09.2021 11:30
            +1

            Вообще-то Королев умер за три года до первого пуска Н1. Понятно что его влияние было весьма велико, но все же такие формулировки — они слегка преувеличенные. В том, что с двигателями не успели (потому что позже эти же двигатели смогли доработать и использовать вполне успешно), или не смогли сделать движок с большей тягой — тоже один Королев виноват что-ли? Любые решения в такой сложной области — плод компромиссов.


            1. BigBeaver
              22.09.2021 11:31

              А вот не умер бы — могла бы и полететь!


              1. sshikov
                22.09.2021 11:43
                +3

                Вообще — совершенно не исключаю. Я учился у В.П.Мишина, и лично его знал, но я его знал как профессора и завкафедрой. По степени «политического» влияния он вероятно уступал Королеву на месте генерального. И то что выше написали про Глушко, вполне могло бы при живом Королеве не прокатить. Так что итог вполне бы мог быть иным. Не знаю уж, каким конкретно (в смысле Луны, например) — но на мой взгляд, успешный испытательный пуск Н1 был вполне возможен.


            1. tzlom
              22.09.2021 19:39
              +1

              Решение поставить кучу маломощных двигателей было принято Королёвым. И двигатели эти разрабатывались под конкретную ракету, он мог принять решение разрабатывать мощные движки, не делать 5 ступеней итд однако что вышло то вышло. Мой посыл был не в том, что Королёв виноват что Н1 не взлетела, а в том что даже визионеры с отличным послужным списком могут ошибаться по крупному.


              1. sshikov
                22.09.2021 20:42

                Да, я вас понимаю, и даже в такой постановке скорее согласен. Но только я немного о другой стороне вопроса. Конечно, за три года со дня смерти Королева до первого неудачного пуска нельзя было поменять его решения. Ну, во всяком случае, принципиальные, т.е. сделать новую ракету. Но можно было с некоторой немаленькой вероятностью запустить эту. И кто тут виноват что не успели — уже сказать точно сложновато.

                Но если его виной считать неверно принятые решения (мне не очень тут нравится это слово, все же это ошибки, но не вина, потому что решения всегда принимаются в условиях неопределенности, и основаны на прогнозах, и не всегда вина человека, что прогнозы эти не точны). Ну да, в провале проекта всегда в большей степени виноват генеральный конструктор, просто потому, что он принимает самые важные решения, и если они неверные — исправить это уже зачастую нельзя.


              1. Nordosten
                22.09.2021 21:58
                +1

                Падала то Н1 не из-за маломолощности движков и не из-за наличия 5 ступеней.

                Проблема в тестировании

                • Поскупились на стартовый стол поменьше чтоб отработать запуск например связки трёх ступеней из пяти. Наработали бы статистику и опыт и времени меньше б ушло чем на год останавливать полеты после взрыва

                • Профукали всё с тестированием движков. Очень ограниченные тесты были, ещё и методом случайной выборки. Военные традиции какие-то.

                • Система управления КОРД была сырая и корявая и как показали полёты себя не дискредитировала


                1. ilvar Автор
                  22.09.2021 23:05
                  +2

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

                  Черток эту всю ситуацию хорошо описал.


          1. ilvar Автор
            22.09.2021 11:34
            +1

            Мне кажется, тут основной фактор - что у Королева был карт-бланш на средство доставки ядерной бомбы (ой, то есть, я хотел сказать, на Спутник и Гагарина), а когда дошло до Луны - сменился генсек и военные приоритеты, сам СП умер, начался "передел рынка" между ракетными и двигательными КБ, а пока вот это вот всё - Фон Браун со своим карт-бланшем добрался до Луны, и политическая ценность программы Н-1 резко упала.

            Для принятия правильного решения нужно уметь задавать правильные вопросы, а тут нужны как собственный опыт, так и быстрый аналитический ум, чтобы моментально распознавать BS в презентациях.


        1. sa1ntik
          28.09.2021 20:53

          Есть еще такая особенность, инженеры склонны преуменьшать важность не-функциональных требований: сроки, стоимость, вот это все.

          Сроки и стоимость это как раз функциональные требования. Они вполне измеримы и понятны. Их появление и образование тоже может быть адекватно объяснено. Могут не обращать на них внимание или склонные к излишнему перфекционизму люди, или те, кому сказали "сделай идеально" без более детальных пояснений.

          Вот некая сферическая эргономика, непонятный дизайн и позиционирование на рынке уже непонятны.

          А цена и сроки реализации включены в требования любого ТЗ.


          1. ilvar Автор
            28.09.2021 23:20
            +1

            Включение требования в ТЗ не делает его функциональным. Функциональные требования - это описание взаимосвязей между входами и выходами системы, ответ на вопрос: "Что должна делать система?" Нефункциональные - описание самой системы (и, если надо, процесса разработки), ответ на вопрос: "Как она должна это делать?"

            То есть, качество кода, производительность, отказоустойчивость, сроки разработки и цена - это все нефункциональные требования.


    1. Aggle
      22.09.2021 06:22
      +7

      У Фейнмана отличная аналогия с "русской рулеткой". А самая наглядная из повседневной жизни - "я столько раз на "красный" переходил - и ничего, живой и здоровый".

      Касательно программы "Space Shuttle" - ровно та же история повторилась потом с "Коламбией". Имеющаяся и хорошо известная проблема (отрыв части плиток) и уверенность, что раз ничего не случалось раньше - то не случится и дальше. Более того - в одной из миссий (STS-27) экипаж шаттла провёл полёт, как на иголках, так как знал, что теплозащита повреждена, причём, возможно, в критичном месте. Но с земли пришёл ответ, типа: "не загружайте себе голову, мы думаем, что ничего с вами не случится". После приземления были констатированы серьёзные повреждения от воздействия температуры, но на проблему забили ещё на 15 лет, вплоть до последнего полёта "Коламбии".


      1. Goodwinnew
        22.09.2021 11:19
        +4

        Режим зануды он

        Русская рулетка - да, это ближе. При выполнении действия (явно разрешенного) всё нормально до определенного момента. Этот момент можно вычислить (в реальности - не всегда).

        Красный светофор - это явное запрещение. Можно даже не знать почему именно. Но периодичность нарушения приводит к проблеме.

        Режим зануды офф.

        :)

        ps

        Про STS-27 не знал, спасибо.

        На твердотопливных ускорителях стояли новые, более легкие, носовые обтекатели. И на 85 секунде полёта носовой обтекатель правого ТТУ стал разрушаться, и его осколки ударили по теплозащитному покрытию шаттла. Происходящее фиксировалось на наземные камеры и не осталось незамеченным. После выведения экипаж развернул манипулятор "Канадарм" с камерой и стал осматривать нижнюю поверхность "Атлантиса". Зрелище было неважным - плитки теплозащиты словно обстреляли из зенитного орудия (а командир Роберт Гибсон воевал во Вьетнаме и видел результат работы зениток). Но, странное дело, ЦУП Хьюстона не видел проблемы. Изображение с камеры передавалось по шифрованному каналу связи (напомним, это военная миссия), шифрование сильно снизило качество изображения, и инженеры на Земле решили, что повреждения являются всего лишь игрой света и тени. И, по совершенно непонятной причине, астронавтам, устно описывающим проблему, не поверили! Хуже того, ЦУП Хьюстона не предпринял никаких мер для получения дополнительной информации. За STS-27 не следили с Земли, не использовали спутники-шпионы, проблему посчитали незначительной. Посадка прошла нормально, но инженеров ждал неприятный сюрприз - при личном осмотре повреждения теплозащитного покрытия выглядели ещё хуже. "Атлантис" получил 707 ударов, пришлось менять от 125 до 175 плиток теплозащиты, а одна плитка с нижней поверхности вообще была сорвана, и алюминий под ней стал плавиться при торможении о плотные слои атмосферы. Астронавтам STS-27 повезло - именно на этом месте крепилась антенна, и корпус был толще обычного.


      1. Mnemone
        22.09.2021 11:26
        +2

        можно не играть в русскую рулетку, а можно заранее убедиться, что револьвер не заряжен

        что именно имеют ввиду люди, которые говорят про переход на "красный"?


      1. ilvar Автор
        22.09.2021 11:35
        +1

        Угу. Хорошо говорить "мы думаем", когда сидишь в теплом ЦУПе, а не в консервной банке готовишься нырнуть в пекло.


  1. Aleksandr-JS-Developer
    21.09.2021 22:25
    +2

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


  1. Old_Chroft
    21.09.2021 23:00
    +1

    Я удивлен, что не упомянут фильм "Челленджер" (2013 года), где как раз эта ситуация и описывается (Пост охватывает проблему несколько шире - но фильм не так уж далек от истины).


  1. Ogra
    22.09.2021 07:23

    Буквально на днях читал это мнение в книге "Радость познания" (сборная солянка из лекций, статей и т.д. Фейнмана)


    1. ilvar Автор
      22.09.2021 11:37

      В сети я не нашел, только ссылаются и цитируют все :)


      1. ivegner
        28.09.2021 16:32

        Может ли это быть как-нибудь связано с исключительными авторскими правами на публикацию? Может ли Ваш пост невзначай их нарушать? Хотя предвижу, что Вы этим вопросом озаботились до публикации.


        1. ilvar Автор
          28.09.2021 17:41
          +1

          Перевод мой, отчет комиссии Роджерса - в public domain


  1. Tyusha
    22.09.2021 09:26

    Надеюсь, Спейс Икс и Илон Маск в частности внимательно читали этот доклад.


    1. ilvar Автор
      22.09.2021 11:39

      Можно для проверки проследить, как у них шла разработка ф1, ф9, посадки, и вот теперь старшипа (хинт: снизу вверх и со сбором максимального количества данных).


  1. trurll
    22.09.2021 12:00
    +4

    Рекомендую к прочтению:

    Верхом на ракете. Возмутительные истории астронавта шаттла | Майк Маллейн.

    Подробно разобраны обе катастрофы шаттлов


  1. pvsur
    22.09.2021 16:44

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


    Золотые слова, но на российский чиновничий не переводятся :(


    1. ukhanov
      22.09.2021 19:38

      Только на российский?


    1. ilvar Автор
      22.09.2021 20:16

      Как вампиры бегут прочь от библии, так государевы люди и подрядчики корёжатся от простой мантры "нет никаких государственных денег, только деньги налогоплательщиков", ага.


  1. speshuric
    22.09.2021 20:02
    +4

    Компьютерная система "Шаттла" очень сложна, она содержит более 250 000 строк кода (ха-ха, прим перев).

    Через 35 лет легко сказать "ха-ха". Глядя на совершенно другие языки программирования на двух тридцатидюймовых мониторах красиво расцвеченные редактором. Пайпалйн сборки, кучка тестов, система контроля версий, мощный компьютер для редактирования кода, stackoverflow.com и миллионные комьюнити. В таких условиях, конечно, "ха-ха". Хотя и сейчас 250 KSLOC интенсивной логики за месяц даже прочитать сложно.

    Но вернёмся в 1970-1980-е годы. Странная дорогая железка (в данном случае вероятно речь о IBM AP-101), причём 99% времени у разработчика может и доступа к ней нет. Язык программирования, по сравнению с котором C - образец читабельности и структурирования (скорее всего HAL/S). Экран чёрно-зелёный 80х25 символов (а может и меньше). Памяти, конечно же не хватит чтоб просто загрузить в память все 250 KSLOC (хорошо, если 1 KSLOC влезет). Терминал компьютера, возможно, доступен по расписанию. Лучший способ читать код - распечатать и разложить закладки. Компиляция и сборка - целое событие. Тестирование в железке - эпохальное событие. Логи тестов, кстати, скорее всего не такие полные, как хотелось бы. Пошаговая отладка отсутствует. Нормальные дампы и инструменты анализа, возможно, тоже. Спеки на железку в печатном виде в коробке.

    Уже и не "ха-ха"


    1. ilvar Автор
      22.09.2021 20:20
      +2

      Это такое "ха-ха", многогранное, да.