Трещины были обнаружены на лопатках турбины многих ТТНВД второй ступени. В одном случае трещины обнаружили после 1900 секунд работы, а в другом они не были обнаружены после 4200 секунд, хотя обычно такие более длительные периоды работы выявляют трещины. Чтобы понимать, о чем здесь идет речь, мы должны осознать, что нагрузка очень сильно зависит от уровня мощности. Полет «Челленджера», как и предыдущие полеты, был на уровне, обозначенном как 104 процента от номинальной мощности в течение большей части времени работы двигателей. Судя по некоторым данным документов, предполагается, что при 104 процентах номинальной мощности трещины не появляются примерно вдвое дольше, чем при 109 процентах, или уровне полной мощности (УПЛ). Будущие полеты должны были выполняться при 109 процентах из-за более тяжелых полезных нагрузок, и очень многие испытания проводились именно при таком уровне мощности. Следовательно, при делении времени при 104 процентах на 2 мы получаем единицы, которые называются эквивалентным уровнем полной мощности (ЭУПЛ). (Очевидно, этим вводится некоторая неопределенность, но она не была изучена.) Самые ранние трещины, упомянутые выше, образовались при 1375 секундах ЭУПЛ.
Теперь правило аттестации стало таким: «ограничить все лопатки турбин второй ступени максимум 1375 секундами ЭУПЛ». Если кто-то возразит, что коэффициент безопасности 2 при этом потерян, то ему скажут, что одна турбина проработала в течение 3800 секунд ЭУПЛ без трещин, и половина от этого 1900, так что мы более консервативны. Мы одурачили самих себя трояко. Первое, у нас есть только один образец, и он не флагман флота: у двух других образцов за 3800 секунд (или больше) ЭУПЛ имелись 17 треснувших лопаток. (В двигателе 59 лопаток.) Затем мы отказались от правила 2x и произвели замену на эквивалентное время (1375). И наконец, 1375 – то, где трещина была обнаружена. Мы можем сказать, что не было найдено трещин ниже 1375, но последний раз, когда мы смотрели и трещин не было, – это 1100 секунд ЭУПЛ. Мы не знаем, когда именно образовалась трещина между этими двумя моментами. Например, трещины могли образоваться при 1150 секундах ЭУПЛ. (Примерно две трети наборов лопаток, тестируемых с превышением 1375 секунд ЭУПЛ, имели трещины. Некоторые недавние эксперименты действительно показали трещины уже при 1150 секундах.) Было важно не снижать это число, так как шаттл должен был использовать свои двигатели очень близко к их пределу ко времени окончания полета.
Наконец, заявляют, что от коэффициента не отказались и что система безопасна, при этом отказываясь от принятой практики ФУГА, что трещин быть не должно и считая отказом только полностью разрушенную лопатку. С таким определением еще ни один двигатель не вышел из строя. Идея состоит в том, что, поскольку есть достаточное время для роста трещины до разрушения, мы можем гарантировать, что все безопасно, проверяя все лопатки на предмет трещин. Если трещины обнаружены, то заменить лопатки, а если ничего не обнаружено, у нас есть достаточно времени для безопасного полета. Таким образом, утверждается, что проблема трещин уже не проблема безопасности полета, а просто проблема технического обслуживания.
Может, это и так. Но насколько хорошо нам известно, что трещины всегда растут достаточно медленно, так что во время полета никакого разрушения не произойдет? Три двигателя проработали длительные периоды времени с несколькими треснувшими лопатками (около 3000 секунд ЭУПЛ), и ни одна лопатка не сломалась.
Можно найти решение этой проблемы. При изменении формы лопатки применяется упрочняющая дробеструйная обработка поверхности, если до изменения новые лопатки не трескались – потом покрыть поверхность изоляцией, что исключает термоудар.
Похожая ситуация просматривается и в истории аттестации КТНВД, но ее детали мы приводить не будем.
В итоге очевидно, что смотры готовности полета и правила аттестации показывают ухудшение в отношении некоторых проблем главных двигателей космического шаттла, почти аналогичное ухудшению, наблюдаемому в правилах для твердотопливных ракетных ускорителей.
Авионика (бортовое электронное оборудование)
Здесь под авионикой подразумевается компьютерная система орбитального модуля, как входные датчики, так и выходные силовые приводы. Сначала мы ограничимся собственно компьютерами и не станем заниматься надежностью входной информации, поступающей от датчиков температуры, давления и т. п., а также тем, насколько точно силовые приводы на выходе – как то́: запуск ракет, механическое управление, дисплеи астронавтов и т. п. – следуют командам компьютера.
Вычислительная система очень детально разработана и содержит свыше 250 000 строк программы. Помимо многого другого программа отвечает за автоматическое управление на всех этапах выведения шаттла на орбиту и за его снижение, пока шаттл не войдет в атмосферу (ниже 1 Маха[60]) и не будет нажата кнопка для выполнения решения о желательном месте посадки. Можно было бы и всю посадку сначала и до конца проводить в автоматическом режиме. (Сигнал выпустить шасси намеренно выведен из-под управления компьютера, это действие должно выполняться пилотом предположительно по соображениям безопасности.) Во время орбитального полета вычислительная система используется для контроля полезной нагрузки, выведения нужной информации на дисплеи астронавтов и обмена информацией с Землей. Очевидно, что безопасность полета требует гарантированной точности этой сложнейшей системы аппаратного и программного обеспечения компьютеров.
Вкратце, надежность аппаратных средств обеспечивается наличием четырех, по сути, независимых идентичных компьютерных систем. Где это возможно, каждый датчик также имеет многократное дублирование – как правило, четырехкратное, – и каждый датчик передает информацию на все четыре линии связи с компьютерами. Если же есть рассогласование в поступающих от датчиков сигналах, то в качестве действующего входного сигнала либо используется определенная средняя величина, либо делается отбор тех значений, которые чаще встречаются в зависимости от обстоятельств. Так как каждый компьютер видит все дублирующие датчики, то все входные данные одинаковы для каждого компьютера, и поскольку алгоритмы, используемые каждым из четырех компьютеров, одинаковы, то результаты на каждом компьютере должны быть идентичными на каждом шаге. Время от времени их сравнивают, но поскольку компьютеры могут работать со слегка отличимыми скоростями, то установлена система приостановок и ждущего режима на определенное время, пока каждое сравнение не будет сделано. Если один из компьютеров не согласуется или запаздывает с готовым ответом, то три других, работающие согласованно, считаются правильными, и компьютер, который ошибся, полностью исключается из системы. Теперь, если из строя выйдет другой компьютер по суждению двух оставшихся, то и он исключается из системы, в этом случае полет не продолжается: начинается снижение к месту посадки и управление берут на себя два оставшихся компьютера. То есть это и есть система с резервированием, так как выход из строя одного компьютера не влияет на выполнение задания. И наконец, в качестве дополнительной гарантии безопасности имеется пятый независимый компьютер, в память которого загружены только программы подъема и снижения и который способен управлять возвращением аппарата на Землю, даже если из строя выйдут более чем два из четырех основных компьютера.
В памяти основных компьютеров не хватает места для всех программ подъема, спуска и полезной нагрузки на весь полет, поэтому астронавты четыре раза загружают нужные программы в память компьютера с кассет.
Требуются гигантские усилия для замены программного обеспечения для столь сложной системы и для проверки новой системы, поэтому аппаратное обеспечение не изменялось с момента разработки транспортной системы шаттла 15 лет назад. Действующее аппаратное обеспечение устарело – например, память старого типа на ферритовых сердечниках. Все сложнее и сложнее найти производителей для поставок таких компьютеров старого образца – надежных и достаточно высокого качества. Современные компьютеры намного более надежны и работают намного быстрее. Это упрощает схемы и позволяет больше сделать. Теперь компьютерам не требуется так много загрузки с кассет, так как их память намного большего объема.
Программное обеспечение проверяется очень тщательно по принципу «снизу вверх». Прежде всего проверяется каждая новая строка программы; затем уже верифицируются разделы программы (модули) со специальными функциями. Область рассмотрения постепенно увеличивается, пока все новые изменения не будут включены в состав всей системы и проверены. Этот полный выход считается конечным продуктом, заново выпущенным. Но группа, занимающаяся верификацией, которая является оппонентом по отношению к группе разработчиков программного обеспечения, работает полностью независимо и тестирует программы так, как это делал бы покупатель выпущенного готового продукта. Существует дополнительная верификация при использовании новых программ в имитаторах полета и т. п. Ошибка на этой стадии верификационного тестирования считается очень серьезной, и ее происхождение изучается очень тщательно, дабы в дальнейшем избегать подобных ошибок. Подобные ошибки, не выявленные на предыдущем этапе опытным путем, были обнаружены раз шесть за все время программирования и изменения программ (для новых или измененных полезных нагрузок). Принцип был такой: вся эта верификация не имеет никакого отношения к программе безопасности; это тест на безопасность в некатастрофической верификации (без учета сценария катастрофы). О безопасности полета можно судить исключительно по тому, насколько хорошо программы ведут себя во время контрольных тестов. Если здесь произойдет отказ, то это будет означать наличие серьезной проблемы и не пройдет незамеченным.
То есть, подводя итог: система проверки программного обеспечения – высочайшего качества. Ничто не указывает на наличие того исподволь происходящего процесса самообмана в пренебрежении стандартами, процесса, столь характерного для систем безопасности твердотопливных ускорителей и маршевых двигателей космического шаттла. И вдобавок как раз недавно имели место предложения руководства урезать такие сложные и дорогостоящие испытания за ненадобностью. Подобным предложениям следует противодействовать, потому что они не оценивают едва заметные взаимные влияния первопричины ошибки, вызванной даже незначительными изменениями программы в той или иной ее части. Но в тех случаях, когда вводится новое значение полезной нагрузки или когда это обусловлено новыми требованиями и модификациями, предложенными пользователями, – в программу вносятся необходимые изменения. Любые изменения обходятся дорого, так как они требуют исчерпывающего тестирования. Правильный способ сэкономить – сократить количество требуемых изменений, но никак не качество тестирования каждого из вносимых изменений.