Когнитивное моделирование зданий

От главного редактора isicad.ru: Статья Александра Ямпольского — главного специалиста ООО ПСП «Стройэкспертиза», Тула — «Революции в проектировании», опубликованная на isicad.ru 24 сентября 2010 года дала толчок одному из самых заметных направлений (можно сказать — потоку) наших публикаций в области AEC-BIM. В каком-то смысле можно сказать, что Ямпольский разбудил Талапова , что само по себе делает Александра одной из фундаментальных фигур отечественного ландшафта «BIM-неBIM».

А.Ямпольского нельзя назвать активным участником легендарных (и местами — скандальных) BIM-дискуссий на нашем портале, однако он регулярно демонстрировал свою позицию в нескольких заметных публикациях: «Технология построения конструктивной модели здания по рабочим чертежам», «Сравнение интерфейсов стандартной BIM-программы и виртуальной программы 2D+», «Алгоритм построения расчетно-ориентированной модели в 2D-редакторе».

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

1. Информация и знания

Итак, исходя из названий, целью традиционного проектирования является создание базы знаний о здании; целью альтернативной технологии — создание информационной модели (базы данных) здания.

Сразу нужно определиться с терминологией. В рамках статьи важен только один критерий — возможность автоматической генерации. То, что можно получить исключительно в результате интеллектуального («ручного») анализа, будем называть знаниями; все остальное, генерируемое автоматически (программно), — информацией или данными.

Простой пример иллюстрирует разницу между информацией и знаниями.

Рис. 1. Информация и знания.

На рис. 1 синие колонки — это данные, полученные в результате моделирования. Красная кривая — результат интеллектуальной обработки этих данных. Утрируя, можно сказать, что синий профиль — это информационная модель, а красная кривая и соответствующая ей формула P(x) = 1 / (σ √2 π) * e… являются проектом.

Второй пример взят из практики проектирования. На рис. 2 в виде небольшого фрагмента представлены данные, автоматически генерируемые расчетной программой.

Рис. 2. Таблица данных по армированию колонн.

Вряд ли эти бесконечные колонки цифр представляют интерес для кого-то еще, кроме расчетчика — автора модели.

На рис. 3 — результат интеллектуальной обработки этого массива информации — то, что нужно всем, и что войдет в готовый проект.

Рис. 3. Проект несущих конструкций здания.

Основное, что нужно подчеркнуть — это существование системного разрыва между информацией и знаниями. Заполнить этот разрыв может только человек (проектировщик).

Что такое база данных — знают все. А что из себя представляет база знаний?

Откройте любой учебник, справочник, сборник научных статей. Увидите текст, формулы, принципиальные схемы, таблицы, условные символы и обозначения. Знания записываются и хранятся в виде языковых, лингвистических структур и моделей. Открыв любой проект, увидим, примерно, то же, что и в «умных» книгах.

Вывод, я думаю, очевиден. Традиционный проект — база знаний о здании — это лингвистическая конструкция, записанная на профессиональном языке. В свете этого определения понятно, почему никак не сбудется прогноз об окончательном вытеснении 2D из проектирования. Электронный кульман — наиболее подходящий инструмент для создания и редактирования лингвистических моделей.

2. Единая модель и единый проект

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

Как обеспечивается единость и согласованность конечного продукта при том и другом способе проектирования?

Сначала об информационном моделировании.

Первое, что нужно сделать (вопреки распространенному мнению) — это исключить визуальный контроль в качестве основного метода согласования моделей. Хорошие иллюстрации на эту тему можно посмотреть по ссылке. Просматривая модель, в большинстве случаев ничего, кроме информационного шума, не увидишь, и, следовательно, не согласуешь.

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

При традиционном проектировании основной метод контроля — визуальный. Грубые, концептуальные ошибки, например такие, как показано ниже, отлавливаются без труда.

Рис. 4. Разрез здания (отсутствует деформационный шов).

С деталями дела обстоят хуже. Без нестыковок, выявляемых только на строительной площадке, не обходится ни один проект.

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

3. Автоматическая генерация модели по рабочим чертежам

Автоматически создать лингвистическую модель на основе информационной модели невозможно. К счастью, обратный процесс не столь бесперспективен. Лингвистическую модель можно интерпретировать и, следовательно, на ее основе можно создавать информационные модели. Первую версию программы — «3D-интерпретатор рабочих чертежей», реализующей эту технологию, можно скачать по ссылке.

В архиве находится пример с чертежами 2-х уровневой подземной автостоянки. Часть рабочих чертежей марки АР показана на рис. 5.

Рис. 5. Рабочие чертежи 2-х уровневой подземной автостоянки (выделены интерпретируемые объекты).

Сгенерированная модель представлена на рис. 6.

Рис. 6. Модель автостоянки.

Что дает появление такой программы?

Во-первых, значительно расширяется функционал традиционной технологии. Теперь проектировщики могут строить модели привычными методами, находясь в привычной среде 2D-редактора. И дело не только в более ясном и однозначном представлении объекта проектирования. Интерпретатор на выходе создает командный файл; в частности, сейчас там команды построения модели в среде AutoCAD. С таким же успехом там могут быть команды управления 3D-принтером, станком с ЧПУ, команды входного языка исходных данных расчетных программ и т.д.

Во-вторых, теперь более четко прослеживается технологическая цепочка создания и согласования проекта:
чертежи (создание) -> модель -> поиск коллизий (согласование) -> корректировка чертежей.

И наконец, многие проблемы, являющиеся камнем преткновения для традиционных систем моделирования, такие как редактирование, совместимость форматов, командная работа, работа в облаках и пр., — либо просто отпадают, либо становятся менее острыми.