Разработка боевых программ в НИИ-5
В. В. Липаев
В бывшем Советском Союзе существовала практически автономная область программирования — разработка больших комплексов для управления системами реального времени. Ее продукцию составляли программные средства для управления противовоздушной обороной, космическими объектами и аналогичными им системами. Использование прошедшего времени вызвано тем, что отрасль пережила почти полный цикл существования: зарождение — бурный расцвет — угасание. Все это произошло за относительно небольшой с исторической точки зрения интервал времени — с середины пятидесятых до начала девяностых годов. И сегодня есть много свидетелей достаточно интересной истории отрасли.
Чтобы вспомнить, как это было, обозреватель PC Week/RE Леонид Черняк встретился и побеседовал с профессором, доктором технических наук Владимиром Васильевичем Липаевым, одним из ведущих специалистов по военным программным системам и методам автоматизации программирования. Работы, в которых принимал участие и которыми руководил Владимир Васильевич, велись в Институте № 5 Главного артиллерийского управления Минобороны, впоследствии переименованного в МНИИПА (Московский НИИ приборной автоматики).
PC Week: Владимир Васильевич, около года я работал в руководимом вами отделе, потом, к сожалению, судьба нас развела. С самого начала меня поразило несоответствие того программирования, которому учили в вузе, описанному в учебниках, и практического программирования в условиях “ящика”.
Владимир Липаев: Неудивительно, можно говорить о существовании с начала 50-х годов двух подходов иди даже двух культур, которые я называю программированием “в малом” и программированием “в большом”. Под первым понимается решение научных и инженерных задач, ориентированных на вычисление некоторого результата, его можно распечатать, вывести на экран, т. е. он представляет собой конечную цель работы. Математическая основа задач позволила очень быстро перейти на языки высокого уровня (в ту пору Алгол, а позже Фортран), под них и создавались универсальные вычислительные машины. Существенно то, что, по нашим меркам, такие задачи относительно невелики, размеры кодов не превышают нескольких тысяч строк.
Параллельно развивалось второе направление, где конечной целью было создание систем, обеспечивающих решение функциональных задач управления в непрерывном режиме и в реальном времени. Для подобных систем размеры кодов исчисляются сотнями тысяч строк.
Принципиально следующее: в решении первых задач принимали участие единицы или небольшие группы человек, а вторые требовали коллективов, насчитывающих сотни специалистов. Непосредственно из этого возникают совершенно иные проблемы и прежде всего необходимость создания иерархически организованных (пирамидальных) команд программистов. На верху пирамиды — ведущие специалисты, генераторы идей, затем следуют руководители функциональных подразделений, далее — программисты разных направлений и, наконец, специалисты по тестированию.
Довольно быстро подобные структуры и соответствующая технология были созданы и успешно функционировали. Теперь они существуют в полуразвалившемся виде в отдельных военных организациях. Утрата достигнутого — колоссальная потеря, потому что область действия больших программистских коллективов вовсе не ограничена системами специального назначения. Сейчас в периоде становления находятся информационные системы для налоговых органов, государственного планирования и управления, социального контроля, в которых с неизбежностью будет востребован опыт, накопленный на военно-промышленных предприятиях.
PC Week: Вы работали в институте, занимавшемся системами управления. Расскажите, пожалуйста, об этом.
В. Л.: Одним из центров создания крупных систем, ориентированных на задачи ПВО, стал институт, который в нашем кругу называли “пятеркой”. Прежде он был известен только приборами для управления зенитным огнем (ПУАЗО; в Санкт-Петербурге, в Артиллерийском музее есть образец ПУАЗО), а потом возникла более масштабная задача, включающая управление ракетными комплексами и авиацией ПВО.
Организаторами и вдохновителями нового этапа стали генеральный конструктор Анатолий Леонидович Лившиц и Залман Михайлович Бененсон. Именно А. Л. Лившиц первым понял решающую роль вычислительной техники для систем такого типа и начиная с 1956 г. внушал всему коллективу предприятия мысль о том, что компьютеры открывают дорогу к созданию новых мощных средств вооружения. Заслуга З. М. Бененсона состояла в том, что он сумел преодолеть сопротивление военных и доказать им роль программного обеспечения. Инерция в восприятии первичности “железа” и вторичности программ была очень велика. Генералам невероятно сложно давалось понимание того, как функциональные задачи можно решать нематериальными средствами. (В подтверждение приведу анекдотический пример из жизни. К одному из начальников МНИИПА пришли на доклад молодые специалисты и сообщили о разработке нового ассемблера. Тот их очень внимательно выслушал, сделал вид, что понял, а затем спросил: “Замечательно, а какие габаритные размеры?”. Дальше — немая сцена).
А. Л. Лившиц и З. М. Бененсон добились своего: если в 1954 г. численность всего института не превышала 400 человек, то к концу 60-х только программистов было свыше 2000. Пришло осознание необходимости разрабатывать не отдельные программы, а проектировать сложные программные комплексы. Именно это и отличало наши подходы от тех, которые существовали в вузах и академических институтах.
Новые задачи управления ПВО потребовали создания территориально-распределенных комплексов с полным телекоммуникационным обменом. Системы должны были функционировать в жестком режиме реального времени, время отклика исчислялось долями секунд, в худшем случае — секундами. Началась организация локальных сетей на командных пунктах для обслуживания множества лиц боевого расчета, работающих как единая команда.
Специфика заключалась в том, что надо было найти надежные решения, используя весьма ненадежные, что естественно для того времени, вычислительные средства. Избыточность предлагаемых программ окупала слабость компьютеров. Создавались специальные операционные системы (ОС), которые принципиально отличались от ОС общего назначения. Компактные ОС должны были в реальном времени воспринимать мощные потоки случайной информации и выдавать решения с минимальными задержками.
Тестирование новых программных систем было совсем не похоже на испытание программ в обычном смысле. Слабость технологии (в те времена программирование велось вначале в машинных кодах, а только потом на языке ассемблера) порождала огромное количество ошибок.
Здесь надо сделать одно отступление, касающееся специфики компьютеров, используемых для управления. Ограниченность ресурсов (производительности, памяти, регистров и т. д.) приводила к необходимости экономить не то что каждый байт, но даже отдельный двоичный разряд. Поэтому создавались машины, архитектура которых соответствовала какой-либо определенной функциональности. Попросту говоря, в систему команд машин входили специальные команды для выполнения конкретного действия, скажем включения или выключения исполнительного органа. А так как задач было много, то соответственно появилось огромное число управляющих машин — до трехсот только в военном применении. И это была вовсе не блажь, как может показаться, а следствие ограниченных возможностей. На плохой и медленной элементной базе создавались скоростные системы. О том, за счет чего это удавалось, можно судить на основании сравнения с отрывочными сведениями о решениях нашего потенциального противника.
Вычислительные ресурсы у американцев были несравненно больше, но стоимость труда программистов там традиционно высока. А мы, как всегда, брали своей изобретательностью и численностью.
PC Week: Руководство СССР недооценило важность развития микроэлектроники. Можно ли считать, что идея универсальных управляющих машин пришла к нам из США?
В. Л.: Не совсем. Необходимость сокращения машинного “зоопарка” была для нас очевидна. Ведь дело доходило до того, что на каждом из десятка типов ракет стратегического назначения для решения задач навигации использовался оригинальный компьютер. Повторяю, это было не самодурство, хотя и присутствовали определенная ведомственность и инерция мышления разработчиков, но универсализм появляется тогда, когда есть некоторая избыточность ресурсов.
PC Week: Решение любой инженерной задачи всегда предполагает поиск компромисса, выход из положения в условиях ограниченных ресурсов — это общее для всех видов инженерии. Как отразились сложившиеся условия на технологии создания ПО?
В. Л.: Прежде всего нужно было наладить взаимодействие между идеологами, руководящими созданием функционально законченных систем, и программистами. Эти две категории людей с трудом находили общий язык. Отсутствие взаимопонимания являлось причиной огромного числа конфликтов, когда каждый сваливал ошибки на соисполнителя.
PC Week: Вы говорите об организационном аспекте технологии, но как практически все это происходило. Писались ли программы непосредственно в кодах боевых машин или уже появились какие-то средства автоматизации?
В. Л.: До какого-то времени альтернативы не было, но в 60-х годах стали доступными универсальные машины, началось создание интерпретаторов, на которых удавалось писать и отлаживать отдельные фрагменты. Подобные интерпретаторы являлись кросс-системами, позволявшими выполнять программы для боевых машин на стандартных, как тогда говорили, ЦВМ. Первые системы такого типа были построены на ЭВМ М-220.
Уже эти способы автоматизации программирования позволили резко сократить число ошибок программирования, но оставались ошибки функционального типа. Возникла необходимость в средствах моделирования внешней среды. Было предложено на специальную широкую магнитную ленту в многоканальном режиме в псевдореальном времени записывать информацию о поведении внешних объектов: о полетах самолетов, действиях специалистов боевых расчетов и т. д. На несложном стенде с помощью таких магнитофильмов оказалось возможным имитировать работу игру всей системы.
К сожалению, в современных условиях стендовые испытания больших информационных систем на соответствие условиям внешней среды практически не проводятся.
PC Week: О таких работах сейчас ничего не слышно. В то же время знаменитая ошибка Y2K появилась как раз из-за недооценки изменений внешней среды и отсутствия тестирования. Если бы при приемке систем прокрутка даты входила в программу испытаний, то такой ошибки попросту не было бы как класса. Если учесть, во что обходится исправление функциональных ошибок, то потерю этой культуры программирования можно считать несчастьем.
В. Л.: Действительно, несчастье. Системы при пиковых нагрузках ведут себя совершенно по-иному, спорадически. Если ваша система работает с одним объектом, то это вовсе не значит, что она будет работать и с тысячью объектов.
Следующим нашим шагом стало создание тестов для оценки нагрузки в реальном времени. Мы смогли без полетов самолетов, без применения другой специальной техники отлаживать комплексы. Представьте себе стоимость и опасность отладки и испытаний на реальных объектах.
Эти работы до сих пор не утратили актуальности. Такие испытания требуются для систем, обслуживающих большое число клиентов. Задачи имитации внешней среды необходимы для обнаружения критических мест в информационных системах. Примеров катастроф из-за программных ошибок немало, по этой причине упала французская ракета “Ариан-5” с очень дорогим спутником, разбилось несколько наших спутников, неудачей закончился запуск аппарата на Марс и т. д. Во всех случаях программные системы не проходили соответствующие стендовые испытания.
Мы должны больше говорить о технологической безопасности как о комплексе мер, направленных на нейтрализацию как внешних, так и внутренних источников опасности. Сейчас нередко более значимой считают внешнюю угрозу, исходящую от некоего врага, однако собственные дефекты систем могут принести огромный ущерб.
PC Week: Итак, к середине семидесятых был уже накоплен определенный технологический опыт, насколько я понимаю, именно в это время начались серьезные работы по автоматизации программирования.
В. Л.: Пойти по пути академического программирования (перейти на языки высокого уровня) мы не могли из-за недостаточности ресурсов, и к тому же оставалась упомянутая проблема комплексной отладки.
Нам требовались системы, которые бы не только проходили обычные этапы компиляции, но и включали спецификации программ и средства автоматического тестирования. Тесты, созданные человеком, контролируют не более 40% маршрутов исполнения программы. Это значит, что свыше половины возможных реакций программ не проверяются вообще и могут вызывать ситуации, чреватые неожиданными последствиями. Создание тестирующих систем распадается на две составляющие: для проверки программы на боевой машине и в режиме интерпретации.
PC Week: Я думаю, что радикальные изменения начались с появлением мощных для того времени машин БЭСМ-6 и старших моделей ЕС ЭВМ.
В. Л.: Апогеем и в общем-то финальным аккордом в нашей работе стали комплексная многофункциональная инструментальная система “Яуза-6” на БЭСМ-6, а затем кросс-система “Руза” на ЕС ЭВМ.
На базе компонентов “Яузы-6” в конце 70-х годов для создания программ первых появившихся в стране микропроцессоров типа Intel 8086 и Intel 3000 была разработана система “Темп”, которая нашла широкое применение при программировании соответствующих встраиваемых микроЭВМ.
На разработку системы “Яуза-6” объемом свыше 350 тыс. строк автокода БЭСМ-6 было затрачено около 400 человеко-лет. К концу 1979 г. кросс-система “Яуза-6” была настроена более чем на 25 архитектур объектных управляющих ЭВМ и передана на эксплуатацию в 14 организаций различных ведомств. Тем самым проявилась высокая рентабельность адаптируемых кросс-систем, которые позволили повысить производительность труда специалистов при создании крупных программ реального времени до 2-5 строк ассемблера в день на человека при высокой эффективности объектного кода.
PC Week: Я бы хотел перевести ваше внимание на язык Ада, ведь он закрывает тот зазор между академическим программированием и программированием комплексов для управления системами реального времени. На Аде можно описывать и внешние условия.
В. Л.: Действительно, Ада — язык для создания систем высокого качества и сложности. Наши “Яуза” и “Руза” были на уровне ассемблеров и макроязыков низкого уровня. Ада отличается более высокой дисциплиной программирования, следовательно, готовые продукты имеют меньше дефектов. Это очень эффективное средство. Мы двигались в данном направлении и почти до конца довели проект под названием Рада, который представлял собой упрощенный вариант Ады.
По ряду причин, в том числе политических, он был остановлен. Очень велика сила инерции всех участников — от программистов до руководителей. Внедрение новых технологий встречало большое сопротивление, которое затрудняло развитие.
В США тоже было огромное сопротивление Аде, но внедрение языка проходило в приказном порядке. Министерство обороны потребовало все свои заказы выполнять на Аде, и сегодня программы для МО пишутся только на Аде, это стандарт.
PC Week: Создавая большие проекты, вы работали со многими замечательными людьми, кого бы вы хотели назвать?
В. Л.: Мне очень в жизни везло на прекрасных руководителей и коллег. С благодарностью вспоминаю совместную работу с Анатолием Леонидовичем Лифшицем, Залманом Михайловичем Бененсоном, Львом Александровичем Серебровским и Павлом Гавриловичем Гагановым. Основными коллегами по боевым программам были Леонид Алексеевич Фидловский, Алексей Иванович Потапов и Петр Иосифович Чуднов, по технологическим работам — Александр Аркадьевич Штрик, Борис Аронович Позин, Феликс Аронович Каганов, Михаил Александрович Минаев, Иван Иванович Савочкин. Вспоминаю очень рано ушедшего от нас Володю Филипповича.
PC Week: Владимир Васильевич, а чем вы занимаетесь сейчас?
В. Л.: За последние годы вышло пять книг, в них, в частности, я пишу о роли стандартизации в программировании и документировании, о надежности программных средств и их технологической безопасности. Все это — переосмысление взглядов, корнями уходящих в тот период, о котором мы с вами говорили.
PC Week: Владимир Васильевич, благодарю вас за очень интересную беседу.
