День 8. Что такое аспос? (Как машины помогают проектировщикам?)

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

Т. Манн, "Доктор Фаустус".

Этот день мы проведем там, где создается система АСПОС.

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

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

Первые попытки использования ЭЦВМ в проектировании датируются пятидесятыми годами и относятся к решению задач расчета конструкций. Это вполне закономерно: теория сооружений - самый математизированный и лучше всего поддающийся формализации раздел строительной науки. И специалисты по строительной механике всегда лучше других ученых-строителей были подкованы в математике. За полтора десятилетия были созданы программы, позволяющие рассчитывать практически

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

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

По замыслу, АСПОС должна свести в единое русло тысячи отдельных программ для строительного проектирования и в результате законченного технологического цикла выдать проектную продукцию. Скажем прямо: АСПОСа как системы пока не существует. Но поговорим о том, какой она нам мыслится и что из уже сделанного может войти в нее.

Деятельность проектировщиков столь много различна, что для полного ее охвата пришлось сразу приступить к членению АСПОСа на подсистемы. Таких главных подсистем набралось несколько - к счастью, для того чтобы их назвать, не стали прибегать к языколомным сокращениям. Бросим беглый взгляд на карту страны. Где-то на ней появятся новые города, рядом с ними возникнут новые заводы. Но где и как должен происходить этот процесс? Как добиться, чтобы не появлялись текстильные города из одних невест и шахтерские из одних женихов? Чтобы прокладываемые дороги не терялись без всякого смысла в непроходимом лесу? Что выгоднее - возить железную руду к людям или перевести людей поближе к руде? А может, лучше всего и тем и другим сняться с места и двинуться навстречу углю? Или нет, не к углю, а к электроэнергии?

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

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

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

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

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

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

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

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

АСПОС - не первая и не единственная в мире система автоматизации проектирования. Еще в 1965 году в США было объявлено о создании системы ICES (integrated Civil Engineering System), то есть Объединенной системы для строительства. Система

ICES включала пять подсистем, которые охватывали вопросы управления и вопросы проектирования строительства, и перво-начальные сведения о ее деятельности были весьма оптимистичны. В дальнейшем сведения о системе ICES несколько утратили мажорное звучание. Лучше всего в ICES был проработан раздел расчета конструкций (так называемая система STRUDL), но и он далеко не всегда оказывался конкурентоспособным по отношению к другим программам по расчету конструкций: часто те работали быстрее и дешевле. В целом как единая система ICES оказалась не состоятельной. В перечне разнохарактерных причин этой относительной неудачи можно упомянуть и то, что в ICES (по крайней мере в разделе проектирования) был реализован программный режим управления без элементов оптимизации. Уже одно пренебрежение оптимизацией предопределило малую эффективность системы.

Известны результаты разработок и других систем автоматизации проектирования за рубежом, в которых удалось избавиться от ряда недостатков системы ICES. В английской системе Genesys, предназначенной для проектирования несущих конструкций, предусмотрели больше возможностей для вмешательства проектировщика в работу алгоритма, для выражения его личных вкусов и привычек. Дело в том, что один из упреков системе ICES связывался с нивелировкой личности проектировщика, что порождало дополнительный психологический барьер. Делались попытки учета в процессе проектирования особенностей каждой страны. Например, создатели японской системы автоматического проектирования стальных конструкций постарались учесть характерное для Японии чувствительное различие в оплате инженеров и неквалифицированных техников: в этой системе подготовку данных для машины могут производить неквалифицированные техники. Системы проектирования создавались также во Франции, ФРГ, Швейцарии и других странах, однако их использование еще нигде не вышло за рамки экспериментирования.

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

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

Но как правильно включить человека в автоматизированную систему проектирования? Как построить систему проектирования, чтобы она не выглядела телегой с реактивным двигателем или престарелой купальщицей в бикини?

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

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

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

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

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

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

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

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

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

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

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

А научные исследования и разработки? Их роль также перманентно растет, а их взаимосвязь с прочими аспектами строительного производства ждет автоматизации. В целом можно себе представить такую схему общей единой автоматизированной системы строительства (рис. 31).

Количество стрелок (1,2,3) ориентировочно указывает на силу связей. Если наши представления об этой силе верны, то отсюда следует, что в первую очередь требуется обеспечить взаимосвязь между системами АСУС и АСПОС. Для осуществления этой связи служат системы АСПВ (Автоматизированная система проектирования возведения) и АСПОР (Автоматизированная система проектирования организации работ). Конкретные формы такой связи многообразны. Отметим лишь, что механическое объединение всех строительных подсистем осуществлялось в американской системе ICES и оказалось, как мы уже говорили, неэффективным. Нужны действенные формы связи, вытекающие из специфики строительного производства.

Попробуем представить хотя бы некоторые из них. Сейчас связи между системами АСПОС и АСУС могут реализоваться лишь в программном режиме: проект считается заданным раз и навсегда. Любые изменения проектного решения, в которых реализуется обратная связь между АСПОС и АСУС, протекают крайне болезненно. Между тем, по некоторым оценкам, мы теряем до 15% всех ресурсов в строительстве из-за невозможности или нерациональности воплощения уже принятых проектных решений в создающихся на стройках ситуациях. Какой же выход может мыслиться в будущем? Выход может состоять в полной отмене понятия "проект" и замене его понятием "алгоритм проектирования". В зависимости от сложившейся на стройке конкретной ситуации с учетом наличия материалов, погодных условий, состояния рабочей силы и техники прораб, обратившись к выносному пульту машины, установленному на участке, получит оптимальный вариант проектной документации, привязанный к сложившимся условиям. Пока еще такая схема невозможна по ряду причин, в том числе по причинам юридическим: прораб не имеет права вносить изменения в проект, поскольку за проект полностью отвечает проектировщик. Но в рамках АСС, автоматизированной системы строительства, объединившей в себе функции АСПОС и АСУС, задача проектировщика будет состоять в создании, вернее формировании из готовых блоков, программы проектирования и инструкции к программе, по которой прораб сможет на месте получать проектную документацию.

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