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

Космическое оружие: дилемма безопасности. Автора- А.Г.Арбатов, А.А.Васильев, Е.П.Велихов...
Москва, Мир, 1986
5.2.3. Проблемы создания математического обеспечения ПБУ и возможности обнаружения ошибок программирования
В первый период широкого обсуждения СОИ проблемы создания математического обеспечения ПБУ системы ПРО оставались в тени и не вызывали серьезного внимания дискутирующих сторон. Внимание как сторонников, так и критиков СОИ было сосредоточено на вопросах создания оружия направленного переноса энергии, на проблемах обеспечения боевых станций энергоресурсами и т.п. Вопросы, связанные с тем, будет ли работать система управления с достаточной надежностью, насколько трудоемка задача ее создания, можно ли избежать ошибок при написании соответствующих программ для ЭВМ ПБУ системы ПРО, рассматривались как сугубо технические. Между тем, одновременно с прояснением ряда научных проблем создания ударного космического оружия технические проблемы, первоначально игнорировавшиеся, стали выдвигаться на передний план.

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

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

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

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

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

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

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

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

Конечно, подобные оценки носят статистический характер, однако приведенные в работе [5.24] многочисленные сравнения теоретических прогнозов с параметрами реальных написанных программ демонстрируют неплохое соответствие.

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

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

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

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

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

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

программы

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

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

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

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

l= 20 x2x5x 30 = 6000.

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

т = 3 х 20 = 60.

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

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

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

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

(5.5)

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

до 2и.

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

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

(5.6)

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

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

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

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

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

Проделанные выше расчеты показывают, что при длине программы - 10 млн. строк относительное число ошибок – 60 на 1000 строк программы – существенно выше цифры, называемой Д.Коэном. Из теории Холстеда следует, что цифры, приводимые Д.Коэном, справедливы лишь для относительно небольших программ. Однако Д.Коэн в своем выступлении ничего не говорит ни о реальных длинах программы для ПБУ противоракетной системы, ни о том, что даже при таком, казалось бы, низком проценте ошибок в реальной программе их число будет составлять десятки тысяч, просто выражая уверенность в преодолимости этой проблемы.

По существу, Коэн лишь эффектно использует риторический прием цифрового опровержения ошибочного утверждения, содержащегося в статье газеты «Нью-Йорк тайме», не рассматривая следствий, вытекающих из его утверждения. А между тем даже одна ошибка в программе (не говоря уже о 104 ошибок) может свести на нет эффективность боевой космической станции и, следовательно, всей системы ПРО. Вместо с тем д-р Коэн признал огромные трудности, стоящие на пути создания ПБУ противоракетной системы, но высказал уверенность, что они могут быть преодолены с помощью методов создания надежных систем из ненадежных элементов, используемых в настоящее время в сетях телефонных коммуникаций [5.27].

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

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

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

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

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

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

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

вернуться к содержанию
вернуться к списку источников
перейти на главную страницу

Релевантная научная информация:

  1. Космическое оружие: дилемма безопасности. Автора- А.Г.Арбатов, А.А.Васильев, Е.П.Велихов... Москва, Мир, 1986 - Технические науки
  2. 5.2.3. Проблемы создания математического обеспечения ПБУ и возможности обнаружения ошибок программирования - Технические науки
  3. 5.2.2. Степень делегирования ответственности - Технические науки
  4. «ОБЪЕКТИВНОСТЬ» СОЦИАЛЬНО-НАУЧНОГО И СОЦИАЛЬНО-ПОЛИТИЧЕСКОГО ПОЗНАНИЯ*1 - Социология
  5. Вильфредо Парето. СОЦИАЛИСТИЧЕСКИЕ СИСТЕМЫ* - Социология
  6. ТЕМА 6. Мир человека как культура - Культурология
  7. 5.2.1. Архитектура подсистемы боевого управления и проблема уязвимости - Технические науки
  8. 1.2. Задачи педагогической науки - Педагогика
  9. 6.7. Деятельность учителя и ученика в различных видах обучения - Педагогика
  10. Образование как система и процесс - Педагогика
  11. Пьер Бурдье. ОПЫТ РЕФЛЕКСИВНОЙ СОЦИОЛОГИИ* - Социология
  12. Язык культуры - Культурология
  13. Религия и наука в контексте культуры - Культурология
  14. Техника как социокулыурное явление - Культурология
  15. 16.2. Экономические кризисы второй половины XX в. - Исторические науки
  16. 21.3. Великая Отечественная война (1941-1945 гг.) - Исторические науки
  17. Введение - Технические науки
  18. 5.1 Подсистема обнаружения,опознавания и наведения на цель - Технические науки
  19. 5.1.1. Требования по разрешению - Технические науки
  20. 5.2. Подсистема боевого управления - Технические науки

Другие научные источники направления Технические науки: