Технические науки

В последнее время интерес к проблемам создания надежно работающего математического обеспечения ПБУ системы ПРО резко возрос. Соответствующие вопросы были поставлены в докладе Комитета советских уче-ых в защиту мира, против ядерной угрозы [5.23]. Появилось значительное исло публикаций на Западе. Эти вопросы стали предметом слушаний в подкомитете по стратегическим и тактическим ядерным силам сената ША.

Ниже мы рассмотрим некоторые технические трудности в создании матобеспечения ПБУ системы ПРО, представляющиеся, на наш взгляд, наибольшим препятствием для реализации программы СОИ, а также проанализируем основные аргументы сторонников СОИ в пользу возможности быстрого преодоления этих трудностей.

Бесспорно, главная трудность в создании матобеспечения ПБУ – его громный объем.

В американской печати упоминались самые различные оценки объема матобеспечения ПБУ – от нескольких миллионов до десятков миллионов строк (операторов Фортрана). Приводились также самые разнообразные

оценки числа возможных ошибок на 1000 строк программы – от 300 (цифра явно сильно завышена) до 0,1. При этом нигде не выдвигалось никаких аргументов в обоснование указанных цифр. Отдавая должное традиционной любви американцев к цифрам, необходимо заметить, что не только в них дело. Одна ошибка в программе на 1000 строк – много это или мало? А одна ошибка на 10 000 строк? Десять миллионов строк программы – насколько это сложно для написания?

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

В настоящее время существуют научные методы [5.24], позволяющие оценить как объем программы, так и возможное количество ошибок в ней, исходя из сложности задачи (на основании количества используемых в задаче аргументов или переменных и ожидаемых результатов).

Попытаемся оценить объем программы матобеспечения, объем операционной системы в центральном процессоре и число ошибок в матобеспечении ПБУ, пользуясь методами Холстеда [5.24].

Если общее число независимых входных и выходных параметров * известно, то число операторов в программе вычисляется путем решения следующих уравнений:

где – параметр, характеризующий язык программирования (для Фортрана среднее значение),, – число операндов в реализации программы (т.е.

Для лучшего понимания смысла введенных переменных отметим, что операторам программы можно поставить в соответствие глаголы естественного языка, а операндам – имена существительные. Если задать , то, решив уравнения (5.3) и (5.4), можно найти, а затем и об-

щее число символов в программе (словарь программы) , и длину

программы

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

Боевая космическая станция системы ПРО в принципе должна быть рассчитана на перехват - 1000 целей с расстояния - 400 км. Для перехвата необходимо рассчитать местоположение целей, их скорость, расстояния до них и условные параметры прицеливания. Оценивая объем программы, мы заведомо упростим задачу и попытаемся получить оценку снизу, не рассматривая ни задачи распознавания, ни задачи согласования полученных данных с моделью стратегической ситуации. Мы рассматриваем максимально простой, с точки зрения создания матобеспечения, случай предельной децентрализации, когда процессор ЭВМ подключен непосредственно к сенсорам станции и обрабатывает координаты наблюдаемых объектов с целью вычислить их положение на момент перехвата.

Ясно, что на каждом экране желательно иметь не слишком много целей. Будем исходить из того, что на БКС имеется достаточное количество экранов и на одном экране появляется не больше 20 целей. Ввиду почти мгновенного действия оружия направленной передачи энергии объект поражения успевает сместиться за время распространения поражающего импульса не более чем на десятки метров.

Как отмечалось выше, для определения природы объекта необходимо измерять несколько параметров К (пусть К = 5). На экране измеряются две координаты для каждого из 20 объектов. Итак, число входных параметров программы равно:

l= 20 x2x5x 30 = 6000.

Выходные параметры программы – это угловые координаты целей и расстояния до них. Для двадцати целей число т выходных параметров составляет

т = 3 х 20 = 60.

Таким образом, обшее число параметров в программе Решая приближенно уравнения (5.3) и (5.4), получаем N ~ 2 * 10⁸.

Итак, для рассмотренного, упрощенного с точки зрения создания матобеспечения, случая мы получили оценку размера программы – более десяти миллионов строк (20 символов в строке в среднем), что примерно в 2 раза превышает объем матобеспечения космических кораблей многоразового использования или крупной телефонной станции общественной телефонной сети США. Именно такого порядка объемы матобеспечения обсуждались в американской печати в связи с проблемами создания ПБУ системы ПРО. Посмотрим, что же случится, если рассматривать не предельно децентрализованный случай процессора, привязанного к группе из пяти сенсоров, а считать, что матобеспечение всей боевой космической станции интегрировано (как оно, конечно, и должно быть). В этом случае число входных и выходных параметров возрастает в 50 раз:

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

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

(5.5)

гдевведены выше, – параметр Страуда, который меняется от 4

до 2и.

Формула (5.5) позволяет получить для первого из рассмотренных случаев, где, время программирования ~ 10'² чел.-ч. Количество

ошибок можно подсчитать по формуле:

(5.6)

Число ошибок для первого из рассмотренных случаев получается порядка 5- 10⁵. Устранение такого числа ошибок, конечно, потребует значительного времени, может быть, намного превосходящего время написания программ.

Вопрос об ошибках программирования и в связи с этим о принципиальной возможности создания ПБУ системы ПРО активно обсуждался в последнее время в американской печати и правительственных организациях. Этой проблеме были посвящены выступления в подкомитете сената США по стратегическим и тактическим ядерным силам двух крупных специали-

стов в области систем связи и их программного обеспечения д-ра Д. Коэна (Институт информатики) и С.Бухсбаума (лаборатория фирмы «Белл»), выступавших в защиту программы СОИ 15.25,5.26]

Рассмотрим их аргументы. Д.Коэн, опровергая данные, сообщенные в статье газеты «Нью-Йорк тайме» от 7.4.85 (где приводилась оценка числа ошибок – 300 на 1000 строк программы), утверждал, что реальное относительное число ошибок должно оцениваться значениями от 0,5 до 3 на 1000 строк программы, а при особо внимательной проверке программы эта цифра может быть понижена до 0,1 ошибки на 1000 строк программы.

Теория Холстеда показывает, что относительное число ошибок зависит от длины программы: при больших длинах оно растет примерно пропорционально логарифму длины.

Проделанные выше расчеты показывают, что при длине программы - 10 млн.

Аналогичную идею развил в своем выступлении и С.Бухсбаум. Он предлагал рассматривать ПБУ как некое подобие большой телефонной сети. При этом, говоря о надежности работы телефонных станций, функционирование которых обеспечивается большими компьютерными программами объемом в несколько миллионов строк, Бухсбаум упомянул, что существуют методы снижения числа ошибок в работе телефонной сети, сводящиеся к дублированию элементов и их самопроверке, и на этом основании де-[ лал вывод о возможности создания надежного матобеспечения ПБУ системы ПРО, хотя также не отрицал чрезвычайной сложности этой задачи. " Действительно, известны идущие еще от К.Шеннона и Дж.фон Неймана [5.28] идеи создания надежных устройств из ненадежных элементов. Несо

мненно, такие устройства могут быть созданы. Прекрасным примером этого являются сверхбыстродействующие ЭВМ, где проблема надежности срабатывания триггеров стоит особенно остро. Разработаны эффективные средства борьбы со сбоями в переключательных устройствах, и доказательством этому является создание ЭВМ типа «Крей».

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

Логарифмический рост относительного числа ошибок с увеличением длины программы – тенденция чрезвычайно тревожная и ставящая под сомнение принципиальную возможность написания программ длиной выше 10⁸ строк. На этот факт до сих пор не обращалось должного внимания. Возможно, что для решения задач, связанных с написанием программ подобной длины, потребуется принципиально новый подход к программированию, а может быть, и новый подход к архитектуре ЭВМ. Человеческий мозг успешно справляется с задачами подобного объема, но он работает, по-видимому, на совершенно иных принципах, являясь самопрограммирующимся устройством. Разбиение программ на модули небольшой длины (лишь длина не более ~ 260 символов гарантирует безошибочность алгоритма [5.24]) не решает проблемы, так как в программах длиной 10⁸ символов число модулей составляет ~ 10⁶, и объединение их (с учетом того факта, что разбиение на модули, вообще говоря, приводит к появлению новых входных и выходных параметров) может стать не менее сложной задачей, чем сплошное написание самой программы.

Оценим теперь объем операционной системы, которая должна управлять деятельностью сети ЭВМ, расположенных на боевых космических станциях. Как отмечалось выше, ЭВМ, обеспечивающие распознавание целей и согласование действий системы ПРО с моделью стратегической ситуации, не могут быть полностью автономными; таким образом, ресурсами этих ЭВМ должен управлять центральный процессор. Можно полагать, что число управляемых ресурсов Rа равно числу станций наблюдения. Тогда число команд в операционной системе (см. [5.24]) определяется по формуле

Нетрудно видеть, что реальное число ресурсов операционной системы Ra не может превышать ~ 30, иначе число команд в этой системе будет порядка 10¹⁰, а операционную систему с таким числом команд написать нереально. В то же время 30 станций наблюдений вряд ли достаточно для создания эффективной системы ПРО.

Проблему построения подсистемы боевого управления с учетом про-анализированых в Комитете советских ученых трудностей в создании операционной системы можно было бы решать путем создания иерархии управляющих станций. В этом случае кроме центральной станции с управляющим процессором должна быть предусмотрена система промежуточных станций, каждая из которых управляет 20 – 30 станциями, непосредственно наблюдающими за обстановкой. Так как для обеспечения непроницаемости системы ПРО необходимо непрерывное наблюдение за территорией, с которой возможен взлет ракет, общее количество станций наблюдений должно быть не менее 200 – 300 и соответственно число промежуточных станций управления должно быть порядка 10. Такая архитектура подсистемы управления, по-видимому, повышает уязвимость космического эшелона противоракетной системы, так как уничтожение нескольких промежуточных станций даже с учетом того, что все элементы этой системы будут работать с «перекрытием», создаст «окно» в системе ПРО и резко I снизит ее эффективность.