Об информационном моделировании зданий (BIM) говорят в последнее время много – не в последнюю очередь благодаря маркетинговой машине Autodesk. Наверное, у многих вообще сложилось мнение, что BIM – это изобретение Autodesk. Я хотел бы рассказать об альтернативной концепции OpenBIM или, точнее, еще об одном взгляде на BIM (идее, технологии, стратегии?) – его разрабатывают компании, входящие в альянс buildingSMART, название которого можно перевести как «Умное здание» или «Строй с умом».

Пару слов на тему «Что такое buildingSMART?». Это международный некоммерческий альянс, поставивший целью разработку технологии комплексного информационного моделирования зданий, основанную на открытых принципах. В частности, альянс разрабатывает и развивает спецификацию стандарта, описывающего общие универсальные данные информационной модели. Этот стандарт многие знают как формат файла IFC – Industry Foundation Classes. Подробнее об альянсе можно почитать на его официальном сайте www.buildingsmart.com. Поддержка IFC-формата объявлена во многих программных продуктах, но наиболее активно этот формат разрабатывают, поддерживают и выстраивают на его базе технологические цепочки проектирования компании, входящие в альянс buildingSMART. В целом альянс активно поддерживают две крупные корпорации:

• немецкая Nemetschek Group, которая, с одной стороны, разрабатывает собственную BIM-платформу Allplan, систему прочностного анализа Scia и систему 3D-проектирования Vectorworks, а с другой – владеет компанией Graphisoft, разрабатывающей очень популярную (в том числе и в России) систему архитектурного моделирования ArchiCAD и перспективную систему экологического анализа EcoDesigner.
• американская Trimble Group, которая разрабатывает интересные решения в областипроектирования и строительства, геодезии и ГИС, сельского хозяйства, управления автопарком и мобильными бригадами. За последние два года эта корпорация приобрела два очень известных бренда: Google SketchUP (решение для концептуального моделирования) и Tekla Structures (BIM-решение для предприятий строительной промышленности).

Но, конечно, этими корпорациями альянс не ограничивается. Например, в buildingSMART также входит норвежская компания Data Design System (DDS), которая разрабатывает инженерную BIM-систему DDS-CAD MEP. Подробнее о решениях компании можно прочитать на сайте www.dds-cad.net/index.php.

Как видим, buildingSMART объединяет совершенно разные компании, создающие профессиональные узкоспециализированные решения, которые отчасти конкурируют, но в целом взаимодополняют друг с друга, охватывая различные проектные дисциплины. Что же они предлагают?

Концепция OpenBIM

Постепенное IT-развитие приводит к развитию принципов проектирования – на смену двумерным кульманам (и САПР) идут системы интеллектуального информационного моделирования. Каждая САПР приходит к своей локальной BIM-идее – единой максимально взаимосвязанной модели в рамках своей специальности.

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

В наибольшей степени оно проработано при использовании 2D-данных – в этом случае используются обычные Xref-ссылки (подложки), которые подкладываются в САПР в качестве фонового изображения, а затем вручную координируются/обновляются/изменяются. Таким образом, в данном случае вопрос взаимодействия фактически сводится к вопросу совместимости 2D-файлов между двумя приложениями. И обычно тут используется *.dwg-формат, который в последнее время научились поддерживать многие САПР – как двумерные, так и трехмерные.

Однако технология информационного моделирования зданий существенно усложняет процесс. Тут уже недостаточно просто передать BIM-модель из одного приложения в другое: в различных программах сложные BIM-элементы зачастую описываются по-разному. Такие объекты содержат не только общие, примитивные геометрические описания (типы 2D-линий, штриховки, высота объекта, ширина и т.п.), но и информационные данные, которые другая программа может просто не понять: например, электротехнические характеристики инженерной подсистемы здания будут на 90% «лишней» нагрузкой в архитектурной BIM-модели.

Вообще проблема интеграции информационных моделей, создаваемых в рамках различных дисциплин, – это не только потеря информации между моделями. Как показывает практика, у разных BIM-моделей различий много больше, чем можно себе представить на первый взгляд. Вплоть до того, что могут различаться даже принципы построения модели. Например, если наложить архитектурную BIM на BIM конструктора, имитирующую физическое воплощение здания (рис. 1), то объект «архитектурная колонна, пронизывающая все здание», не будет соответствовать нескольким колоннам, которые будет использовать инженер-конструктор; перекрытие в архитектурной модели будет лежать в других пространственных координатах и иметь другую геометрию по сравнению с плитами перекрытия инженера-конструктора, защемленными в стенах. А если учесть, что над зданием работают не менее десяти специальностей, каждая из которых создает от одной до пяти моделей, то идея собрать все виды BIM-моделей в один универсальный инструмент (среду, файл, базу данных) вообще представляется многим специалистам утопической.

Участники альянса buildingSMART выступили с более реалистичной инициативой: а что если оставить возможность создавать специализированные, проработанные в рамках одной-двух-трех специальностей BIM-модели в тех решениях, которые лучше всего это делают, а затем связывать модели между собой в тех частях, которые требуют согласования? В оригинале эту идею назвали «reference-model based BIM workflows», то есть BIM-проектирование, основанное на связанных моделях. В отличие от закрытых (проприетарных) BIM, стратегия открытой BIM предоставляет следующие преимущества:

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

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

OpenBIM = Открытое взаимодействие

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

Этап №1 – фильтрация элементов

Как я уже говорил, архитектурная модель не просто избыточна для конструктора, она даже геометрически отличается от того, что желает получить конструктор. Посмотрите на рис. 2, где здание представлено таким, каким его видит архитектор: там есть отделка стен, оконные переплеты, декоративные конструкции. Чертежи содержат полную толщину стен с учетом отделочных слоев, могут содержать ненесущие перегородки, подвесные потолки, плитку, полы, фурнитуру дверей – все то, что очень важно с точки зрения архитектора (и заказчика), но непринципиально для конструктора. Несущий конструктив здания в этой модели тоже представлен, но он а) построен в соответствии с пониманием архитектора (и, скорее всего, будет скорректирован конструктором после расчетов); б) спрятан внутри здания и его невооруженным глазом не видно.

Как же отключить лишнее, убрав архитектурную «шелуху»? Вот тут и начинается фильтрация элементов: с помощью слоев и настройки отображения элементов в BIM-модели архитектора отключается лишняя с точки зрения конструктора информация. Визуально это похоже на здание на этапе строительства (без отделки) – это и отключение целых категорий объектов (подвесных потолков, остекления и т.п.), и соскабливание отделочных материалов с несущих элементов. Остается «голая» несущая часть здания (рис. 3).

Функция фильтрации элементов очень элегантно решена в ArchiCAD: используются комбинации слоев и функция отображения ядра несущих элементов (свойство «Несущий элемент» или «Ненесущий» задается в параметрах объекта). Это позволяет практически моментально упростить модель, исключив из нее явно «лишние» объекты, и затем постепенно донастраивать модель до приемлемого уровня фильтрации. А потом моментально вернуться в исходное состояние и продолжать архитектурный BIM-проект.

Этап №2 – классификация элементов

Достаточно ли отключить «лишние» элементы для того, чтобы передать конструктору устраивающую его BIM-модель? Как показывает практика – нет. Помните, я говорил о том, что архитектор по-своему смотрит на здание? «Играя» с объемами здания, его формами, постоянно изменяя их, архитектор использует те элементы, которые ему удобнее всего для работы: подвесные потолки могут быть созданы с помощью перекрытия; элементы декора – посредством профильных стен; оконные проемы – вычитанием геометрии произвольной формы, полученной из 3ds Max (универсальный объект с точки зрения ArchiCAD). Тут, если мы хотим сохранить удобство САПР как инструмента, нет четких методов и правил – ведь, заставляя проектировщика использовать определенный инструмент для выражения идеи, мы ограничим его в свободе проектирования. Поэтому и получается, что объект, который визуально выглядит как колонна, на деле тонкая высокая стена или толстое перекрытие. Или визуально целая фронтальная стена на деле может состоять из нескольких фрагментов, распределенных по вертикали и сливающихся при визуализации и генерации чертежей.

В результате полученную информационную модель приходится тем или иным способом классифицировать дополнительно – либо объекты выкладывают на определенные слои, либо в другое приложение они передаются несколькими файлами, содержащими объекты одного типа, либо настраивается карта соответствия, которая зависит от проектировщика или стандарта предприятия и используемых программных продуктов. Кстати, в свое время именно последним путем пошла команда SCAD Group, когда связывала ArchiCAD и SCAD: она разработала препроцессор «Форум», который объекты ArchiCAD 6.5 классифицировал в объекты SCAD и затем передавал данные на прочностной расчет.

В системах проектирования, поддерживающих OpenBIM, должен быть инструмент, который позволяет дополнительно классифицировать используемые в BIM-модели элементы, задавать им универсальную метку, описывающую этот объект. На данный момент такую метку дают в соответствии со спецификацией формата IFC – универсального языка строительных конструкций, что-то типа эсперанто в архитектурно-строительном BIM-мире.

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

• архитектор может создавать объем (BIM-модель) любыми инструментами, которые ему удобны: экспортировать модель извне, формировать объектами ArchiCAD, трансформировать их с помощью инструмента свободного моделирования (Морф). Объекты можно располагать на любой слой – никаких четких правил и требований в этой части нет;
• в свойствах каждого элемента есть характеристики, которые классифицируют элемент по различным направлениям: архитектор может задавать несущую функцию элемента (которая также помогает при фильтрации модели – см. этап №1), расположение объекта (интерьерный объект либо экстерьерный), статус реконструкции (объект под снос, вновь возводимая или временная конструкция) и класс элемента (рис. 4). О последнем поговорим подробнее.

В ArchiCAD класс элемента можно назначать по умолчанию – он будет соответствовать тому инструменту, которым этот объект создан: стена в другую BIM-систему будет передана как стена; колонна – как колонна; балка – как балка. Но можно класс и переопределять – в этом случае, например, ограждение вы можете создать либо с помощью инструмента Навесная стена, либо как объект, либо как морф-элемент, но в другую систему оно будет передано именно как ограждающий элемент! Плюс к тому стандартные свойства объекта можно расширять параметрами, описанными в спецификации IFC: класс огнестойкости объекта, уровень звукопоглощения, шумовой защиты, коэффициент теплопроводности, описание и т.д. – доступны более тысячи параметров и характеристик, определяемых открытым стандартом IFC (рис. 5). И если это необходимо для интеграции с другой BIM-системой, архитектор может заполнять эти свойства или импортировать их из других систем. В этом плане – абсолютная свобода.

Итак, мы научились не просто отсекать лишнее, передавая данные из одной BIM-модели в другую. Мы научились еще и перенастраивать модель под ожидания другой программы. Теперь нам остается сохранить эту модель в универсальный обменный формат (IFC-файл), а затем этот файл открыть в BIM-решении получателя.

Этап №3 – получение модели

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

На первых шагах вы, скорее всего, захотите получить модель для того, чтобы быстрее начать работу, сократить время построения своей BIM-модели. И, скорее всего, тут вас ждет разочарование – полученная таким образом BIM будет непригодна. Почему? Да потому что изначально импортируемая BIM-модель не создавалась для вас. При ее создании задумывались о совершенно других вопросах, обладали совершенно другими знаниями. И, надо полагать, эту модель вы полностью перестроите.

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

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

1. Самый простой и очевидный путь: открыть все объекты, сохраненные в IFC-формате, и, считав их данные, построить в своей модели аналогичные объекты автоматически. Например, в IFC-файле сохранена колонна высотой 3 метра, с профилем «тавр по стандарту G, серия M», расположенная по координатам X, Y, Z. Программа считывает эти данные и создает аналогичную (по характеристикам) колонну. Можете назвать недостатки такого подхода? Их много, но назову глобальный – при повторном экспорте вы получите еще одну колонну. Десятки экспортов (а они без сомнения будут в процессе работы над проектом) – десятки дублей.

2. Второй путь более сложен: построить связь между объектом в IFC и объектом в вашей BIM-модели, а затем синхронизировать изменения между этими базами данных. Тут уже можно размышлять о двусторонней связи между двумя независимыми BIM-решениями. Это и есть идея связанных моделей.

Тем, кто заинтересован этой технологией, рекомендую посмотреть, как IFC-модель, созданная в ArchiCAD, сейчас принимается в программном продукте Tekla – это один из возможных путей.

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

Важно заметить, что вторая IFC-модель (от конструктора к архитектору) не обязательно содержит данные из первой IFC-модели (от архитектора к конструктору). Если это необходимо, она может дополнять (расширять) информацией объекты архитектора: например, добавить/заполнить класс огнестойкости для колонны – может быть, архитектор передаст эти данные другим специалистам. Но в простейшем случае (а, скорее всего, именно так сейчас и делают) конструктор может передать только созданные в его приложении объекты, которые также можно связать с моделью архитектора по технологии связанных моделей.

Этап №4 – возврат модели и обратное согласование

При возврате модели очень важно проработать вопросы «как отображать объекты, которые уже добавлялись в модель» и «что с этими объектами произошло за время согласования». То есть синхронизовать изменения. Опять же отвечать на эти вопросы каждое решение будет самостоятельно – четкие правила еще вырабатываются. Сейчас выведены четыре стадии объектов:

• новый объект, еще не добавлявшийся в текущую BIM-модель, – «new»;
• объект существует и не изменялся с точки зрения текущей BIM-модели – «existing»;
• объект существует и изменялся – «modified»;
• объект удален – «deleted».

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

Что касается «existing»-объектов, мы можем просто принять обновленные данные (опять же, если они были). Например, изменилась толщина колонн, мы принимаем эти изменения – и прекрасно, если толщина стен предусматривала увеличение габаритов колонны. Если нет, то перестраиваем свой проект.

Коллизия с удаленными объектами тоже будет решаться просто – если вы удалили объект в своем проекте, то он либо не влияет на вашего коллегу, либо вы уже согласовали с ним удаление объекта. В любом случае надо бы обновить вашу IFC-модель у конструктора, чтобы пронести изменения по всем разделам.

И самый сложный случай – если объект в вашем проекте изменен, а во внешней BIM-модели остался прежним. Тем более если на базе устаревших данных принимаются решения в соседних отделах. В этом случае необходимо оперативное согласование изменений и решение коллизий при синхронизации.

Посмотрите пример работы вот в этом ролике:

Заключение

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

И еще один момент… В самом начале я говорил, что идея OpenBIM еще только развивается. Сейчас очень мало открытой информации по тому, как в реальности работает OpenBIM, с каким проблемами сталкиваются пользователи, как их решают. Мало примеров, оформленных в виде статей, файлов, нормативов, стандартов и других документов. Почему? Потому что практическая реализация идеологии OpenBIM еще только формируется. Компании, которые инвестируют в эту технологию, еще только прорабатывают механизмы, набивают шишки…

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

Удачи!

Денис Ожигин,

директор по стратегическому развитию

ЗАО «Нанософт»

www.nanocad.ru