isicad.ru :: портал САПР, PLM и ERP :: версия для печати

Статьи

21 января 2013

Концепция OpenBIM: понятие, принципы реализации, некоторые выводы

Денис Ожигин

От редакции isicad.ru: Мы уже сообщали нашим читателям о программе Open BIM, запущенной альянсом buildingSMART в марте 2012 г. А сегодня с удовольствием публикуем статью Дениса Ожигина, директора по стратегическому развитию компании «Нанософт», в которой он подробно раскрывает эту тему.
Обзорную статью на тему BIM для ресурса isicad мне предлагали (тем или иным способом) написать несколько раз, но каждодневная загрузка не позволяла этого сделать: надо было сесть, аккуратно разложить по полочкам то, что накопилось в голове за последние несколько лет, что-то еще раз для себя прояснить. И вот наступили новогодние праздники, появилась возможность немного расслабиться, сконцентрироваться на определенной теме — и мысль сформировалась. Насколько интересно — судить вам.

Итак, об информационном моделировании зданий (BIM) говорят в последнее время много — не в последнюю очередь благодаря маркетинговой машине Autodesk. Наверное, у многих читателей isicad вообще сложилось мнение, что 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-моделей в один универсальный инструмент (среду, файл, базу данных) вообще представляется многим специалистам утопической.

Рис. 1. Многообразие BIM-моделей: здание в представлении различных специалистов различно

Участники альянса buildingSMART выступили с более реалистичной инициативой: а что если оставить возможность создавать специализированные, проработанные в рамках одной-двух-трех специальностей BIM-модели в тех решениях, которые лучше всего это делают, а затем связывать модели между собой в тех частях, которые требуют согласования? В оригинале эту идею назвали «reference-model based BIM workflows», то есть BIM-проектирование, основанное на связанных моделях. В отличие от закрытых (проприетарных) BIM, стратегия открытой BIM предоставляет следующие преимущества:
  • в каждом проекте САПР-менеджеры могут использовать индивидуальный набор инструментов, который состоит из наилучших в своей области решений и оптимально решает поставленные проектные задачи;
  • менеджеры проектов осуществляют полный контроль над составными частями проекта (в том числе и над обновлением независимого друг от друга программного обеспечения) без потери сроков проектирования;
  • использование набора решений сокращает риск потери данных, в отличие от работы с единой BIM-моделью (которая объединяет несколько специальностей, но результаты хранит в одном файле). Конечно, можно сохранять резервные копии единого файла, контролировать слияние данных, раздавать полномочия по редактированию, но все это дополнительные административные ресурсы, которые в критический момент могут подвести;
  • менеджеры проектов могут отказаться от сложной настройки универсального BIM-файла, заточенного под все виды специальностей, а использовать отдельные модели, созданные в независимых программах и связанные между собой1;
  • как результат, проектировщики получают понятную BIM, выстроенную на открытых стандартах, что позволяет использовать данные на всем жизненном цикле здания: от строительства до реконструкции или разрушения.
Стратегия OpenBIM универсальна и предназначена не только для разработчиков программного обеспечения. Она ориентирована на любых специалистов, работающих на рынке архитектурно-строительного проектирования и выстраивающих концепцию BIM. Понятно, что на данный момент стратегия не имеет окончательно сформированного варианта — эта идея оттачивается на реальных проектах, меняется, развивается. А вот как она видится на сегодняшний день, с какими тонкостями сталкиваются сейчас — в следующих темах статьи.
1На мой взгляд, это одна из ключевых проблем — удачная на первый взгляд настройка универсального файла к середине проекта может стать тем камнем, который потянет на дно весь комплексный BIM-проект.
OpenBIM = Открытое взаимодействие
Давайте теоретически промоделируем процесс междисциплинарного BIM-взаимодействия и для этого представим себе двух его участников — отправителя и получателя. Важно учесть, что эти участники представляют две разные специальности — пусть это будут архитектор и конструктор. И пусть в данном случае архитектор будет передавать данные из своей BIM-модели конструктору.
Этап № 1 — фильтрация элементов
Как я уже говорил, архитектурная модель не просто избыточна для конструктора, она даже геометрически отличается от того, что желает получить конструктор. Посмотрите на рис. 2, где здание представлено таким, каким его видит архитектор: там есть отделка стен, оконные переплеты, декоративные конструкции. Чертежи содержат полную толщину стен с учетом отделочных слоев, могут содержать ненесущие перегородки, подвесные потолки, плитку, полы, фурнитуру дверей — все то, что очень важно с точки зрения архитектора (и заказчика), но непринципиально для конструктора. Несущий конструктив здания в этой модели тоже представлен, но он а) построен в соответствии с пониманием архитектора (и, скорее всего, будет скорректирован конструктором после расчетов); б) спрятан внутри здания и его невооруженным глазом не видно.

Рис. 2. Архитектурное отображение BIM-модели: отделочные слои, декоративные конструкции и т.п.

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

Рис. 3. Очищенное архитектурное отображение BIM-модели, готовое к экспорту конструктору

Функция фильтрации элементов очень элегантно решена в 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). О последнем поговорим подробнее.

Рис. 4. Классификация элементов позволяет более точно передавать модель из одной BIM-среды в другую

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

Рис. 5. BIM-система, совместимая с принципами OpenBIM, должна уметь не только классифицировать свои элементы в соответствии с единой спецификацией объектов, но и расширять характеристики своих объектов свойствами, описанными в стандарте IFC

Итак, мы научились не просто отсекать лишнее, передавая данные из одной 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 — это один из возможных путей.

Рис. 6. Данные, сохраненные в промежуточный формат IFC, можно по-разному интерпретировать со стороны получателя — тут нет универсальных правил

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

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

Этап № 4 — возврат модели и обратное согласование
При возврате модели очень важно проработать вопросы «как отображать объекты, которые уже добавлялись в модель» и «что с этими объектами произошло за время согласования». То есть синхронизовать изменения. Опять же отвечать на эти вопросы каждое решение будет самостоятельно — четкие правила еще вырабатываются. Сейчас выведены четыре стадии объектов:
  • новый объект, еще не добавлявшийся в текущую BIM-модель, — «new»;
  • объект существует и не изменялся с точки зрения текущей BIM-модели — «existing»;
  • объект существует и изменялся — «modified»;
  • объект удален — «deleted».
С новыми объектами все ясно — они отображаются в вашей модели в виде геометрии с информационными характеристиками. И вы принимаете новые решения с учетом их существования — например, можете сделать перекрытие толще, чтобы учесть крепеж и армирование колонны (а за этим, возможно, пойдут изменения в фундаментных помещениях и т.д.).

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

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

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

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

Рис. 7. Пример работы ArchiCAD-Tekla: возврат данных и контроль изменений BIM-моделей

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

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

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

Удачи!

Денис Ожигин,
директор по стратегическому развитию
ЗАО «Нанософт»
www.nanocad.ru

Комментариев: 34
id 9887     25 января 2013, 19:14
 GKCHP
По поводу Strucad, Tekla и Trimble - http://www.tekla.com/uk/about-us/news/pages/acecad-switched-strucad-to-tekla.aspx

Ответить   Цитировать выделенное

id 9889     25 января 2013, 20:58
 Ирина Чиковская
Ответ смерть упырям

Цитата из Денис Ожигин, id 9859:

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



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

Ответить   Цитировать выделенное

id 9891     25 января 2013, 21:38
 Денис Ожигин
Ирина, я бы сказал, что это основная цель для руководителя, но не исполнителя. И согласись, что хороший руководитель и раньше мог вполне нормально оценить риски, выраженные в денежном эквиваленте. Используя для этого не BIM, а просто вникая в проект, опрашивая исполнителей, ГИПов, ГАПов. Согласна?  

Мне кажется, что с этим сложно не согласиться, поэтому продолжу мысль   Если ставить оценку риска как основную цель, тогда получается, что BIM нужен тем руководителям, которые не способны старыми инструментами оценивать эти риски. Т.е. если совсем все упрощать - BIM нужен слабым руководителям, которые не погружены в состояние дел по проекту... Тут уж я совсем глупость сказал, но все следуя логике...  

Ровно поэтому, мне кажется, что оценка рисков - это одна из целей, но все-таки не главная. Главное в BIM - это согласованность рабочих чертежей и сокращение не стыковок. Отсюда уже и возможность работы с более сложными проектами (или сокращение сроков при той же сложности проектов), и возможность оценить риски за счет наглядного представления и быстрого получения отчетов по проекту, и отсутствие страха перед процессом внесения изменений, и многое другое...

Хотя это, конечно, философский вопрос. Просто BIM для каждой группы специалистов, вовлеченных в процесс, дает свои преимущества.

Ответить   Цитировать выделенное

id 9892     25 января 2013, 21:42
 Александр Бауск
>И всю эту работу должен возглавить какой-то единый государственный орган.

Денис, не думаю так, - видя, как работают наши и ваши государственные органы на фронтире технологий. Нужна коллаборация специалистов по разным профилям - как это и делается в разработке IFC. Возможна ли такая коллаборация в СНГ - вот острый вопрос.

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

Ответить   Цитировать выделенное

id 9907     28 января 2013, 13:34
 Денис Ожигин
>> Денис, не думаю так, - видя, как работают наши и ваши государственные органы на фронтире технологий. Нужна коллаборация специалистов по разным профилям - как это и делается в разработке IFC. Возможна ли такая коллаборация в СНГ - вот острый вопрос.
Так и есть. Поэтому формат IFC надо делать открытым и в русскоговорящем сегменте - чтобы обсуждали, развивали, дорабатывали... Но все равно нужен кто-то кто будет локомотивом этого процесса: либо госорганы, либо ВУЗы, либо отдельный специалист... Но это не должен быть вендор - вендор автоматически начнет этот стандарт затачивать под себя.

Ответить   Цитировать выделенное

id 10294     17 февраля 2013, 6:13
 Владимир Попов
Статья хорошая, спасибо автору.
Хочется высказаться, хоть и с опозданием.
Мне кажется, что будущее BIM за мультиплатформенными решениями (Revit, Bentley). Хотя и тому и другому нужно еще хорошенько подтянуться в соответствующих дисциплинах и за Tekla, и за ArchiCAD'oм, да и за Allplan'ом. Строить линейку BIM в проектировании, намного проще на базе единого формата (разрабъотка модели по дисциплинам, обмен, обновления). Создание альянсов типа OpenBIM шаг абсолютно вынужденный и состав участников, вышеназванного альянса, как раз очень показателен (каждый хочет заполнить свои пробелы в функционале). Что же касается качества обмена через IFC, то тут многие авторы высказались вполне определённо о его практическом состоянии на сегодня. Конечно хотелось бы иметь эту замечательную интероперабильность, чтобы работать с лучшими в своем классе продуктами, да и просто не зависить от монополии тех или иных вендоров, но пока это скореее мечта, чем реальность.

Ответить   Цитировать выделенное


Поля, помеченные * обязательны для заполнения

  Имя *

  e-mail

  web

Вы можете ввести не более 3000 символов, осталось:

Введите
первые 3 символа:

 *

Обновить



    

Комментарии:
21 января 2013, 21:38
 Владимир Шебастюк
Очень хорошая статья, спасибо!
Все то что я предполагал об openBIM оказалось правдой. Любой инструмент предоставляющий обмен с мягкими ограничениями необходимо будет "затачивать" на месте. В принципе, как и обмен данными в 2D посредством DWG формата (тоже очень универсального), который может быть осуществлен только при очень жесткой дисциплине и уровне регламентации на каждом из этапов.

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

Ответить   Цитировать

21 января 2013, 23:17
 Денис Ожигин
По поводу одного или нескольких файлов тут без сомнения надо делать резервирование и прочее... Это даже не надо обсуждать - резервирование должно быть. Но резервирование - это борьба с последствиями. В статье обращается внимание на другую часть - на степень риска потери проекта целом... Поясню.

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

Ответить   Цитировать

22 января 2013, 0:42
 Бусов Александр
1) В рамках большого проекта однозначно нужно разделение моделей. Когда проекты измеряются сотнями + у них есть разные ревизии + разные поставщики оборудования, контрагенты. Тут только Navigator/Navisworks/BIMSight и то на отдельного человека  

2) Очень интересное направление работы, хорошо если они доточат в рамках своих продуктов полнофункциональную работу.

пример из практики по работе IFC:

Столкнулись с тем что Navisworks некорректно читает IFC с Allplan.
Начали проводить опыты на простом элементе: закладная из уголок+анкера и отзеркалированная копия

Корректно IFC из Allplan открывали/импортили:
-DDS-CAD viewer
-Tekla BIMSight
-Acad MEP
-и вроде Nemetschek IFC Viewer

Проблемы вылезли в
- Navisworks (некорректное зеркалирование деталей, кроме того например некорректно вырезаются проёмы разделяющие панель пополам)
- Revit (вообще отзеркаленную деталь удалил, оставив только одну из них)

Также с IFC проблемы у Advance steel были на экспорте.

В итоге представители автодеска согласились с багом:
http://forums.autodesk.com/t5/Autodesk-Navisworks/NW-Mirrors-parts-from-IFC/m-p/3420063/highlight/true

До сих пор баг к сожалению присутствует... Видно незачем его править, если глючит обмен с конкурентом  .

Ответить   Цитировать

22 января 2013, 0:43
 Владимир Талапов
Интересная статья. Сформулирую несколько замечаний:

1. Цитата: "Сегодня я хотел бы рассказать об альтернативной концепции OpenBIM или, точнее, еще об одном взгляде на BIM (идее, технологии, стратегии?)"

Это не альтернативная концепция BIM, а некоторые вынужденные и совершенно естественные действия перечисленных компаний по согласованию имеющихся у них программ. Альянс создан для решения проблем, характерных только для этих компаний. Таких проблем взаимодействия архитекторов и конструкторов ни у Autodesk (в Revit они вообще работают с одним и тем же файлом), ни у Bentley или GT нет.

Долгое время концерн Nemetschek пытался решить эти проблемы самостоятельно, но потом решил, что "ум хорошо, а два лучше", и объединился с Trimble, что весьма разумно.

2. Цитата: "в отличие от работы с единой BIM-моделью (которая объединяет несколько специальностей, но результаты хранит в одном файле)"

Единая модель в одном файле говорит либо о небольшой модели, либо о неопытности пользователя. Обычно же единая модель - это много файлов, но согласованных между собой.
http://isicad.ru/ru/articles.php?article_num=15056

3. Цитата: "будьте уверены – в мире появились компании, которые не просто ушли вперед. Они оторвались вверх, сделали то, что кроме них не смог сделать никто."

Создание альянса - естественная и правильная попытка перечисленных компаний догнать ушедших вперед конкурентов. Пока состояние дел в альянсе оптимизма не внушает. Но хочется пожелать авторам этой задумки успеха!

Ответить   Цитировать

22 января 2013, 0:45
 Евгений Ширинян
Мне статья понравилась. Живой язык, хорошие пояснения.
Нет карт процесса, которые могли бы быть очень простые, но с ними было бы проще.
Этот текст, как и многие другие, рассматривает горизонтальную связь внутри проектной модели(интегрированной). Интересно было бы узнать побольше о строительной модели и ее специфике. Будем ждать текстов от О.Пакидова.
Также пока провисает концептуальная стадия и ее представление в виде модели; именно она закладывает основу успешного проекта, так как там могут быть приняты принципиальные решения. Об этом немало написано у Чака Истмана

Ответить   Цитировать

22 января 2013, 1:49
 Бусов Александр
Цитата из Владимир Талапов, id 9826:

догнать ушедших вперед конкурентов. Пока состояние дел в альянсе оптимизма не внушает.


А каких можно назвать конкурентов "ушедших вперёд" которых догоняет, например, Tekla Structures по части металла?
http://topengineer.ru/sample - Это уже прошлый век ?

Или Allplan по части КЖ ?

Tekla Structures купили Strucad, недавно приглашения только об обмене на Tekla рассылали. Можно на фактах, в чём их состояние дел плохое?

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

Ответить   Цитировать

22 января 2013, 3:26
 Денис Ожигин
Согласен с Александром по поводу Теклы - она смотрится намного профессиональнее Revit Structure. От себя добавлю, что ArchiCAD намного сильнее Revit в части архитектуры... Поэтому спишем фразу "догнать ушедших вперед конкурентов" на маркетинговый троллиг )

А вот то, что в Revit слабая поддержка IFC - это я видел еще 2 года назад на конференции Graphisoft, когда в ArchiCAD только начали активную разработку IFC поддержки. Тогда они столкнулись с тем, что штатный импорт IFC работает некорректно: пропадало часть объектов, оси не конвертировались в оси Ревит. Разработчики Архикад обратились к разработчикам Ревит, но в ответ получили письмо, что мол замечание получено, но сейчас планов по исправлению нет. Тогда Graphisoft сами написали addon к Ревит (благо API открыт) и сами стали импортировать IFC файл в среду Revit - этот путь был более качественный ))

Ответить   Цитировать

22 января 2013, 6:28
 Владимир Талапов
Цитата из Денис Ожигин, id 9829:

2 года назад на конференции Graphisoft, когда в ArchiCAD только начали активную разработку IFC поддержки

Цитата из Денис Ожигин, id 9829:

Тогда Graphisoft сами написали addon к Ревит (благо API открыт) и сами стали импортировать IFC файл в среду Revit - этот путь был более качественный ))

Цитата из Владимир Талапов, id 9826:

Альянс создан для решения проблем, характерных только для этих компаний. Таких проблем взаимодействия архитекторов и конструкторов ни у Autodesk (в Revit они вообще работают с одним и тем же файлом), ни у Bentley или GT нет.

Это и означает догонять конкурентов.

Ответить   Цитировать

22 января 2013, 9:52
 Бусов Александр
Денис, а к Вам небольшой off-topic вопрос, но очень большой wish-list от наших электриков   :

Являемся пользователями nanoCAD-Электро и nanoCAD-СПДС.
На рабочем месте имеем две лицензии, nanoCAD-Электро и nanoCAD-СПДС. Очень неудобно работать в разных приложениях одновременно, приходится закрывать проект в Электро и открывать в СПДС для редактирования строительной подосновы или оформления разрезов трасс. Хотелось бы иметь возможность использовать функции СПДС в среде Электро.
Как на рабочих местах оборудованных связкой АвтоCAD + СПДС GraphiCS, где функции СПДС интегрированы в интерфейс АвтоCAD.

Ответить   Цитировать

22 января 2013, 10:17
 Владимир Шебастюк
Цитата из Денис Ожигин, id 9824:
...молятся на системных администраторов и скрещивают пальцы "дай Бог, чтобы система резервирования не подвела".

Молится в храмах надо, а на работе нужно работать=) А если серьезно, то мое мнение, что гораздо проще организовать нормальное резервное копирование, чем консистентность нескольких источников данных. Поэтому я бы все же сказал, что система с множеством источников ведет себя по-другому: ни лучше, ни хуже, просто по-другому.

2Владимир Талапов: Разработка и продвижение открытого стандарта совершенно не показывает ничью продвинутость или отсталость. Если у Autodesk есть своё полное семейство продуктов интегрируемых на своем формате, то это не значит, что у того же Autodesk нет проблем с интеграцией с то же Tekla Structures.
Тут следует не забывать, что вопрос интеграции может возникнуть не только в рамках одной организации, где мы можем привязаться к одному вендору. Очень часто бывают ситуации, когда приходится работать с подрядными организациями, а вот тут заставить контору, делающую свою работу в Tekla Structures, сделать её в Revit Structures потому что у вас только софт Autodesk, интегрирующийся только со своими продуктами, будет немного странными и не совсем рациональным.
Поэтому развитие таких открытых стандартов очень важно для индустрии в целом, а не только для группы вендоров с ПО не покрывающим полный цикл проектирования.

Ответить   Цитировать

22 января 2013, 11:15
 Регина М
Цитата из Владимир Шебастюк, id 9832:

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

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

Ответить   Цитировать

22 января 2013, 14:10
 Денис Ожигин
Ух, развернутые ответы на комментарии в статье могут потянуть на новую статью…   Ответы последовательно:
2 Евгений Ширинян:
1. карты процесса – ой, я все-таки не настолько ученый муж   Даже мыслей в этом направлении не было…
2. «Интересно было бы узнать побольше о строительной модели и ее специфике». Тут я не специалист, не сталкивался. Чисто логически это задача планирования и организации – мне кажется, что нет большой необходимости в динамической связи с системами проектирования. Учитывая, что сейчас более критичной является связка архитектор-инженеры, то я пока глубоко в следующие стадии не заглядывал.
3. «провисает концептуальная стадия и ее представление в виде модели». Частично, свое мнение на эту тему я затронул на этапе №3, второй абзац:
«На первых шагах вы, скорее всего, захотите получить модель для того, чтобы быстрее начать работу, сократить время построения своей BIM-модели. И, скорее всего, тут вас ждет разочарование – полученная таким образом BIM будет непригодна»
Мне кажется, что это же относится и к концептуальной модели, которая еще более отличается от рабочей архитектурной модели, чем архитектурная от инженерной. При концепции архитектор в большинстве случаев вообще не задумывается о конструктиве, о том, как «правильно» выстраивать модель. Я бы даже посмел высказать мысль, что на этапе концепции модель не является BIM-моделью – скорее рисунок здания, контур.
И идея передавать эту концепцию в BIM-модель на мой взгляд утопична – слишком много надо будет настраивать карт соответствия, фильтровать модель и т.п. Оценивая трудозатраты к результату – мне кажется, что после согласования концептуальной модели с заказчиком правильнее заново отстроить архитектурную BIM-модель, которая будет использоваться для генерации архитектурных рабочих чертежей.
И в первую очередь мои слова справедливы для крупных проектов. Делаю эту оговорку потому, что, без сомнения, все сильно зависит от проекта, его размера, степени детализации – если проект небольшой (интерьер ресторана, например), то можно делать концепцию в ArchiCAD (например, с помощью Морф), потом ее доработать в рабочую BIM-модель, потом ее отфильтровать и классифицировать для передачи в конструкторские и инженерные BIM, а потом все собрать в единой среде – Нэвисворкс или том же ArchiCAD. Но на крупных проектах думаю, что модель надо будет перерабатывать – особенно учитывая, что только архитектурная модель может доходить до 1-2 Гб в виде файла, а в памяти может развернуться и до 8 Гб. При таких размерах проекта на данный момент существует реальная опасность уткнуться в аппаратные возможности железа.

Ответить   Цитировать

22 января 2013, 14:20
 Денис Ожигин
2 Владимир Шебастюк:
Цитата из Владимир Шебастюк, id 9832:
Молится в храмах надо, а на работе нужно работать=) А если серьезно, то мое мнение, что гораздо проще организовать нормальное резервное копирование, чем консистентность нескольких источников данных. Поэтому я бы все же сказал, что система с множеством источников ведет себя по-другому: ни лучше, ни хуже, просто по-другому.

  Согласен – разные подходы и каждый выбирает для себя то, что ему удобнее. Но, по моему мнению, неплохо было бы прогнать на тестовых проектах оба подхода…

2 Бусов Александр:
Цитата из Бусов Александр, id 9831:
Денис, а к Вам небольшой off-topic вопрос, но очень большой wish-list от наших электриков :
Являемся пользователями nanoCAD-Электро и nanoCAD-СПДС.
На рабочем месте имеем две лицензии, nanoCAD-Электро и nanoCAD-СПДС. Очень неудобно работать в разных приложениях одновременно, приходится закрывать проект в Электро и открывать в СПДС для редактирования строительной подосновы или оформления разрезов трасс. Хотелось бы иметь возможность использовать функции СПДС в среде Электро.
Как на рабочих местах оборудованных связкой АвтоCAD + СПДС GraphiCS, где функции СПДС интегрированы в интерфейс АвтоCAD.

Если проводить аналогии с AutoCAD-платформой, то тут надо говорить об единовременной интеграции Project Studio Электрика и СПДС GraphiCS – у СиСофт Девелопмент есть под AutoCAD так называемый «CS интегратор», который позволяет совмещать два профиля независимых программ в рамках объединенного профиля и работать двум программам в одном сеансе.
То же самое мы планируем под nanoCAD – может быть несколько удобнее.

А по wish-list надо бы обратиться к разработчикам nanoCAD Электро – у них есть API для работы с элементами оформления СПДС. Поэтому, если будут запросы от пользователей, то они могут включить функционал СПДС внутри Электро через пару версий.

Ответить   Цитировать

22 января 2013, 14:24
 Денис Ожигин
2 Регина М:
Цитата из Регина М, id 9834:

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

1. Группа фирм не такая уж и узкая. В любом случае, их больше, чем одна компания Autodesk, которая разрабатывает проприетарный RVT формат для BIM, к которому никто кроме Autodesk доступа не имеет.
2. Это не планы; с этим уже работают компании в Америке, Финляндии, Германии. Вот статья в блоге на тему интеграции ArchiCAD с Revit через IFC формат на примере отеля:
http://blog.graphisoftus.com/graphisoft/archicad-15/cjmws-hotel-indigo-project-calls-for-ifc-exploration
И на русском: http://archicad.ru/events/news/20130116-0000.html

Ответить   Цитировать

22 января 2013, 15:21
 Architector
Цитата из Денис Ожигин, id 9837:

Вот статья в блоге на тему интеграции ArchiCAD с Revit через IFC формат

Я не пойму, зачем интегрировать ArchiCAD с Revit, если ArchiCAD, как здесь говорится, намного лучше?

Ответить   Цитировать

22 января 2013, 15:32
 Денис Ожигин
Цитата из Architector, id 9838:

Я не пойму, зачем интегрировать ArchiCAD с Revit, если ArchiCAD, как здесь говорится, намного лучше?

Я сравнивал ArchiCAD и архитектурный Revit и отдельно это подчеркивал... Как вы, наверное, знаете, Revit'ов в свое время было три: Architectural, Structure и MEP. Подозреваю, что имеется в виду интеграция ArchiCAD как архитектурного решения (используемого в архбюро CJMW) и Revit как решения для конструкторов.

Собственно, это действительно имеет смысл - цена Revit ниже, чем у Tekla (насколько я знаю). Плюс Revit в Америке для конструкторов более привлекателен, чем в России, благодаря более тесной поддержке стандартов проектирования. Ну, а ArchiCAD для конструкторов никогда и не позиционировался - это не его область.

Ответить   Цитировать

22 января 2013, 15:51
 Олег Т.
Сейчас трансляторы в IFC, насколько я понимаю, встроенные в ПО. (?)
А внешние бывают? Например, для преобразования распространенных форматов, таких, как DWG?
Это было бы очень интересно на практике, мне кажется.

Ответить   Цитировать

22 января 2013, 16:00
 Денис Ожигин
В ArchiCAD для каждого экспорта свой тип трансляторов. На вскидку:
* Есть трансляторы для импорта-экспорта в *.dwg-формат. Они определяют слои, толщины и типы линий, правила формирования штриховок и т.п.
* Есть трансляторы для импорта-экспорта в *.IFC-формат. Они определяют какого класса объекты сохраняются, как нумеруются и т.п.

Сейчас в ArchiCAD встроено 4 транслятора по DWG и 11 трансляторов по IFC (для интеграции с Autodesk Revit Structure, с Autodesk Revit MEP, Bentley Building, BIM 2010, DDS-CAD MEP, Nemetschek Allplan Engineering, Scia Engineer, Tekla Structures и три общих).

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

Ответить   Цитировать

22 января 2013, 17:42
 Олег Т.
Ответ Денис Ожигин

Спасибо.
Оказывается, что-то похожее должно быть в DDS-CAD Viewer.
Supported file formats: View Ifc, IfcZip, gbXML, DWG and DXF. Export Ifc, IfcZip, DWG, DXF, DWF and 3DS

Ответить   Цитировать

22 января 2013, 17:58
 Владимир Малюх
Цитата из Олег Т., id 9840:

Например, для преобразования распространенных форматов, таких, как DWG?


Не очень понятно что из DWG в IFC преобразовывать. DWG не содержит описаний архитектурно-строительных объектов, его содержимое - суть линии, окружности, дуги, тексты и все.

Ответить   Цитировать

22 января 2013, 18:11
 Олег Т.
Ответ Владимир Малюх

Есть что преобразовывать. Как и в 3DS, грани, например. Ну а в программах типа AutoCAD Architecture - те же объекты. Но там, естественно, есть свои преобразователи.

Ответить   Цитировать

23 января 2013, 1:07
 Олег Пакидов
Очень хорошая своевременная статья. Спасибо! С Вами мы встречались в Набережных Челнах при презентациях разработок NanoCAD, где-то года два тому назад. Теперь полностью я уверен, что владеете всем спектром коллизий на уровне проектирования и грамотно преподнесли проектному сообществу их проблемы. Процесс формирования Модели согласно «BIM стандарта» (пример английского) должен быть поэтапно зафиксирован отдельными стадиями разработки – «РАБОТА В ПРОЦЕССЕ», «СОГАСОВАНИЕ», «ОБЩАЯ», «УТВЕРЖДЕНО» и все эти коллизии хранятся в «АРХИВЕ», тогда разговор о потерях информации излишен. По всей видимости, все это должно быть размещено в «хранилище COBie – ПРОЕКТ» где степень защищенности зависит от принятого «BIM стандарта» и конкретного Заказчика. Все это отдельная стадия процесса инвестиционного проекта в целом.
Как строитель, получаю в производство утвержденную Заказчиком «Проектную Модель» и смету. Это совокупность «Архитектурной + Конструктивной + МЕР Моделей» вместе взятые где, на основании «спецификаций BIM проектирования» произведен расчет сметой стоимости каждого «элемента здания», которые доступны для дальнейшего использования. При этом сметные расчеты производятся программными продуктами - воспринимающую Российскую сметную базу данных виде ТЕР, ФЕР, ТЭСН и Фирменных единичных расценок и т.д. Бухгалтерский учет 1С тоже построен на базе российской сметной нормативной базы. Учет выполненных работ – КС-2, КС-3, материальный отчет производителя работ М-29 и т.д. Теперь «Проектная модель» без всяких проектных коллизий должна иметь «элементную базу» равную представленной расчетной единицей предусмотренных в сметном расчете как денежного документа взаиморасчета с Заказчиком. Поэтому меня интересует как строителя «элементная база» по которой я получаю деньги.
А история создания проекта совершенно не интересует меня как строителя. Теперь у меня возникают проблемы разложить стройку по вертикали (возведению) и по горизонтали временного производства работ с поставкой конструкций и материалов, обеспечением подъемными механизмами и инструментом и в конечном итоге обеспечить квалифицированными строительными кадрами для выполнения строительства «точно в срок» и «с наименьшими затратами». Под сметную стоимость получить аванс на строительство, заказать материалы на основе российской квалификации и кодирования. По всей видимости - необходима «Строительная Модель». На этом перевале необходима единая доступная «элементная база здания» хранимая в хранилище «COBie СТРОЙКА» со своими расчетными данными необходимыми для строительства.
По моим понятиям все это должно быть отражено в «Российском BIM стандарте». Российский IFC (rusIFC) должен быть узаконен, поддержка и накопление через Российское Объединение RuSBIM наподобие BIMS (американского), NBS (английского), Lexicon (Голландского) и еще 23 страны мира, которые входят в альянс buildingSMART.
OpenBIM, несомненно, должен быть прописан и в России.

Ответить   Цитировать

23 января 2013, 14:50
 Денис Ожигин
Олег Игоревич, да, я помню нашу встречу. В целом, я думаю, все примерно так как вы описывает и получится... Звучит, по крайней мере, очень логично. Единственно, что я не очень уверен в корректности термина rusIFC - насколько я понимаю из описания, он все-таки лежит чуть в стороне; в увязке передаточных форматов (типа RVT, IFC, gbXML и т.п.) с нашими стандартами. Но ощущение создает, что он заменяет западный IFC на какой-то наш (российский) IFC...

Без сомнения, мы должны увязывать наши строительные стандарты (ГЭСН, правильно?) с различными BIM представлениями, чтобы автоматизировать интеграцию как со сметными программами, так и с ПОС/ППР, но это же параллельная работа, верно? Учитывая то, что Запад еще сам прорабатывает эти стандарты для себя, мне кажется, что правильнее было бы заняться сейчас анализом западных стандартов и участием в разработке общемирового стандарта параллельно увязывая его на наши условия и реалии. Особенно учитывая то, что IFC стандарт открытый для участия.

И всю эту работу должен возглавить какой-то единый государственный орган. Я пока не понимаю, кто это мог бы делать и нужно ли это вообще кому-то...

Ответить   Цитировать

24 января 2013, 16:22
 Luka
Денис, я через свою призму вижу вопрос Олега.
Такой БИМ не купит строитель и монтажник, соответственно не купит эксплуатация. Читай - инвестиций нет и тема либо загнется, либо будет слабо пульсировать в очень ограниченной сфере в виде научных изысканий. Для проектной организации стоимость эксплуатации БИМ очень высока и ложится она в затраты на проект, где маржа сейчас и так низкая.
Помимо запроса выше, строитель, монтажник и эксплуатация попросят упаковать туда еще и документацию - проектную, рабочую, исполнительную, нормативную, паспорта, инструкции (список от 100 наименований и десятки, сотни тысяч ученых единиц - экземплятов) обеспечить функциональность поддержки их (документов) жизненного цикла и падаем в PLM.
Цитата: "Итак, об информационном моделировании зданий (BIM) говорят в последнее время много – не в последнюю очередь благодаря маркетинговой машине Autodesk", я бы сказал так, те производители, которые не имеют наработок в строительной сфере по PLM-решениям. Те же вендоры, которые в портфолио имеют такие решения - о БИМ не судачат - это локальная временная задача для маленького (с точки зрения жизненного цикла) фрагмента PLM.
Вот сольет Автодеск свой Волт со строительными и технологическими вертикалками на уровне данных и пойдет другой маркетинг ...

P.S. Спасибо за статью, всегда радует (завидую) когда кто-то занимается реальной аналитикой.

Ответить   Цитировать

24 января 2013, 19:55
 Денис Ожигин
Стоп-стоп, Luka )))
Я рассматриваю BIM в первую очередь как инструмент проектировщика. BIM-модель можно потом использовать при строительстве и эксплуатации, но это не основная его задача. И все вопросы, которые я рассматриваю в статье – это BIM для проектирования и взаимодействия в рамках разных специальностей, но проектных! И BIM точно не система документооборота организации, которая хранит и согласует всю документацию по проекту. Не документация должна храниться в BIM, а BIM должна лежать в системе документооборота. И должна увязываться с прочими документами логическими связями PLM.
BIM необходим, в первую очередь, для того, чтобы получить согласованную рабочую документацию; чтобы переложить рутинные операции по «протаскиванию» изменений через чертежи на машину; чтобы лучше представлять сложные по форме проекты; чтобы иметь единое представление проекта между кучей специальностей, которые работают над проектом... Поэтому BIM как раз для проектных организаций, в которых маржа низкая – современное средство автоматизации позволит получить больше проектов/денег и выполнить их в срок с приемлемым качеством. А следовательно, повысить эту самую пресловутую маржу проектной организации.
>> Те же вендоры, которые в портфолио имеют PLM-решения - о БИМ не судачат...
Конечно, не судачат – у них другие большие задачи, которые лежат параллельно. Плохо, если они не будут считаться с BIM, но имхо PLM должны забираться внутрь BIM и забирать необходимые данные из базы данных BIM – на SQL, через IFC или еще как-то...

Ответить   Цитировать

24 января 2013, 23:00
 Владимир Талапов
Цитата из Денис Ожигин, id 9859:

Я рассматриваю BIM в первую очередь как инструмент проектировщика.

Цитата из Денис Ожигин, id 9859:

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

Цитата из Денис Ожигин, id 9859:

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

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

Ответить   Цитировать

25 января 2013, 11:57
 KOPEHEB
Ответ Luka
Боюсь, что в ПГС и Нефтянке даже термины разные   Строитель и Монтажник это разные специальности. Эксплуатация объекта недвижимости (Даже самого навороченного "офиссного центра") и маленького НПЗ это как велосипед и космический корабль. Так что в ПГС имеет место быть информационная модель. ИМХО.
PS:Luka рад что вылез из берлоги  

Ответить   Цитировать

25 января 2013, 15:06
 смерть упырям
Цитата из Бусов Александр, id 9828:

Tekla Structures купили Strucad, недавно приглашения только об обмене на Tekla рассылали. Можно на фактах, в чём их состояние дел плохое?


это ЛОЖЬ, т.к. и TEKLA, и STRUCAD куплены TRIMBLE. Правда в том, что TRIMBLE назначила менеджеров из TEKLA руководить направлением.


Цитата из Владимир Талапов, id 9826:

Создание альянса - естественная и правильная попытка перечисленных компаний догнать ушедших вперед конкурентов. Пока состояние дел в альянсе оптимизма не внушает. Но хочется пожелать авторам этой задумки успеха!


это ЛОЖЬ! Альянсы типа OpenBIM, FIATECH, и т.п. создаются для организации нормального взаимодействия потребителей систем и обеспечения конкурентного бизнеса.

Например, не секрет, что для удовлетворения потребностей проектирования с использование ПО требуется гораздо больше, чем может предложить отдельный вендор (будь это Autodesk, Graphisoft, Bentleyили Нанософт) - т.е. нужно обеспечить взаимодействие!

Можно пытаться объединить все в рамках одного вендора и прикрыться форматами как Autodesk и Intergraph. В итоге, масса решаемых (различными путями) и нерешаемых проблем для потребителя. Главной их которых необходимость согласия с требованиями этих компаний и лишить себя возможности выбора инструмента на свое усмотрения.

Можно поддерживать универсальные "форматы" - IFC/ISO15926/.../STEP
В этом случае интероперабельность обеспечивается для всех желающих входящим в альянс. Но, есть проблема! Она в том, что устройство ПО у разных вендоров не всегда может обеспечить должную интерпретацию универасльного формата. Это как русский язык: вроде он общий для нас, но Савицкий и Талапов не могут найти понимание... тяжело "троллям" на одной площадке ;)

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

Ответить   Цитировать

25 января 2013, 19:14
 GKCHP
По поводу Strucad, Tekla и Trimble - http://www.tekla.com/uk/about-us/news/pages/acecad-switched-strucad-to-tekla.aspx

Ответить   Цитировать

25 января 2013, 20:58
 Ирина Чиковская
Ответ смерть упырям

Цитата из Денис Ожигин, id 9859:

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


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

Ответить   Цитировать

25 января 2013, 21:38
 Денис Ожигин
Ирина, я бы сказал, что это основная цель для руководителя, но не исполнителя. И согласись, что хороший руководитель и раньше мог вполне нормально оценить риски, выраженные в денежном эквиваленте. Используя для этого не BIM, а просто вникая в проект, опрашивая исполнителей, ГИПов, ГАПов. Согласна?  

Мне кажется, что с этим сложно не согласиться, поэтому продолжу мысль   Если ставить оценку риска как основную цель, тогда получается, что BIM нужен тем руководителям, которые не способны старыми инструментами оценивать эти риски. Т.е. если совсем все упрощать - BIM нужен слабым руководителям, которые не погружены в состояние дел по проекту... Тут уж я совсем глупость сказал, но все следуя логике...  

Ровно поэтому, мне кажется, что оценка рисков - это одна из целей, но все-таки не главная. Главное в BIM - это согласованность рабочих чертежей и сокращение не стыковок. Отсюда уже и возможность работы с более сложными проектами (или сокращение сроков при той же сложности проектов), и возможность оценить риски за счет наглядного представления и быстрого получения отчетов по проекту, и отсутствие страха перед процессом внесения изменений, и многое другое...

Хотя это, конечно, философский вопрос. Просто BIM для каждой группы специалистов, вовлеченных в процесс, дает свои преимущества.

Ответить   Цитировать

25 января 2013, 21:42
 Александр Бауск
>И всю эту работу должен возглавить какой-то единый государственный орган.

Денис, не думаю так, - видя, как работают наши и ваши государственные органы на фронтире технологий. Нужна коллаборация специалистов по разным профилям - как это и делается в разработке IFC. Возможна ли такая коллаборация в СНГ - вот острый вопрос.

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

Ответить   Цитировать

28 января 2013, 13:34
 Денис Ожигин
>> Денис, не думаю так, - видя, как работают наши и ваши государственные органы на фронтире технологий. Нужна коллаборация специалистов по разным профилям - как это и делается в разработке IFC. Возможна ли такая коллаборация в СНГ - вот острый вопрос.
Так и есть. Поэтому формат IFC надо делать открытым и в русскоговорящем сегменте - чтобы обсуждали, развивали, дорабатывали... Но все равно нужен кто-то кто будет локомотивом этого процесса: либо госорганы, либо ВУЗы, либо отдельный специалист... Но это не должен быть вендор - вендор автоматически начнет этот стандарт затачивать под себя.

Ответить   Цитировать

17 февраля 2013, 6:13
 Владимир Попов
Статья хорошая, спасибо автору.
Хочется высказаться, хоть и с опозданием.
Мне кажется, что будущее BIM за мультиплатформенными решениями (Revit, Bentley). Хотя и тому и другому нужно еще хорошенько подтянуться в соответствующих дисциплинах и за Tekla, и за ArchiCAD'oм, да и за Allplan'ом. Строить линейку BIM в проектировании, намного проще на базе единого формата (разрабъотка модели по дисциплинам, обмен, обновления). Создание альянсов типа OpenBIM шаг абсолютно вынужденный и состав участников, вышеназванного альянса, как раз очень показателен (каждый хочет заполнить свои пробелы в функционале). Что же касается качества обмена через IFC, то тут многие авторы высказались вполне определённо о его практическом состоянии на сегодня. Конечно хотелось бы иметь эту замечательную интероперабильность, чтобы работать с лучшими в своем классе продуктами, да и просто не зависить от монополии тех или иных вендоров, но пока это скореее мечта, чем реальность.

Ответить   Цитировать

Все права защищены. © 2004-2024 Группа компаний «ЛЕДАС»

Перепечатка материалов сайта допускается с согласия редакции, ссылка на isicad.ru обязательна.
Вы можете обратиться к нам по адресу info@isicad.ru.