Всё про IFC

Способы связки чертежей с моделями в IFC. Ранее мы говорили, что для связки модели и чертежей необходимо обеспечить целостность данных в ИМ ОКС. Стремления закрепить в Градкодексе цифровую информационную модель только усилит эту необходимость. И раз уж решили идти по этому пути, то сразу надо подумать наперед о том, как: 1️⃣ обеспечить единовременную выгрузку модели и листов чертежей из САПР; 2️⃣ связать 2D-объекты на чертежах с элементами модели; 3️⃣ связать табличные данные (ведомости и спецификации) с элементами модели; 4️⃣ обеспечить возможность просмотра видов (разрезов, сечений) в пространстве модели вместе с аннотациями и штриховками чертежа. 🔍 Способ 1. Связь IFC и SVG По этому пути двигается Bonsai (ex. BlenderBIM). Виды и аннотации создаются в редакторе, сохраняются в IFC. Сам лист чертежа оформляется и экспортируется в популярный векторный формат SVG с XML-разметкой, где 2D-объекты имеют IfcGUID для связи с элементами модели. И тут каждый SVG-файл - это отдельный лист чертежа. Из минусов: не решена проблемы 1 и 4. 🔍 Способ 2. Связь IFC и XPS Формат XPS создавался как замена PDF, но с XML-разметкой, и в этом его главный плюс. Спецификация формата зарегистрирована как открытый международный стандарт. В отличие от SVG имеет постраничную структуру, как и PDF, и может содержать в одном файле множество листов чертежей. Связь между моделью и чертежом также реализуется с помощью IfcGUID. Старый формат DWFx от Autodesk был реализован на базе XPS. Выгрузка чертежей в XPS есть у Renga, правда IfcGUIDов мне в нем найти не удалось. У первых двух способов важно, чтобы САПР сохранял виды/разрезы в IFC. Не каждое ПО это умеет. Но почти каждое умеет работать с отчетами в BCF, а значит: 🔍 Способ 3. Связь IFC и BCF Идея принадлежит Игорю Шерстенникову: настраиваются нужные виды с координатами камеры и ракурсом и выгружаются в BCF, который может содержать скриншот чертежа. Понадобится только автоматически наложить аннотации на каждом виде и смотреть их в пространстве модели. Но тут возникают доп вопросы, как будут созданы аннотации в IFC? Подход сейчас проходит апробацию и есть первые результаты. Этот способ подразумевает уход от оформления листов, а это рождает описанные ранее проблемы. Конечно, есть еще вариант полностью отказаться от чертежей, но пока тут много подводных камней. 👥 @IFC_ru 👥 @IFC_club

IfcCheckingTool_Lite - инструмент проверки семантической и синтаксической корректности IFC Эта небольшая программка проверяет IFC-файл на корректность семантики и синтаксиса (то есть верификация данных). При проверке учитываются версии IFC-схемы, начиная с IFC2X3, в форматах файлов SPF (STEP Physical File) и ifcXML. В сгенерированном отчете результаты могут быть отсортированы по различным критериям. Для каждой ошибки предоставляется гиперссылка на соответствующее определение в спецификации IFC, а для отображения ошибки в экземпляре документа может быть использовано окно навигации EXPRESS. 🔍 СКАЧАТЬ 👥 @IFC_ru 👥 @IFC_club

Связка IFC и чертежей: проблема целостности данных Мы уже 8 лет работаем с моделями в IFC и убеждены, что главный вызов при их использовании - обеспечить непротиворечивость между моделью и документацией. И если модель и чертеж живут отдельной жизнью, то всё рушится: 🔹 доверие к модели падает; 🔹 автоматизированные проверки становятся бесполезными игрушками; 🔹 теряется практическая значимость в создании реестра машиночитаемых нормативных требований, а также ГОСТов, ПНСТ и СП, где представлены требования к наполнению моделей; 🔹 BIM/ТИМ превращается в действия ради действия, а не в рабочий инструмент. Как этого избежать? Предложу несколько путей, но везде есть свои подводные камни (если найдете еще, пишите!): 🔹 Полная поддержка стандарта IFC. Риски: ➡️не все вендоры могут/хотят ее реализовать; ➡️хотя в IFC есть всё касательно 2D, но сами листы реализуются путем ссылочных документов. 🔹 Отказ от 2D-документации. Риски: ➡️не отлажены процессы использования различными участниками строительного цикла; ➡️понадобятся удобные и простые инструменты для работы только с 3D, чтобы это не усложняло, а упрощало работу; ➡️придется переписывать нормативку, которая в принципе "устоялась" и работает; ➡️не всё 3D одинаково полезно и быстро: многие до сих раcкладывают арматуру в 2D. 🔹 Новый формат или нативные форматы САПР. Риски: ➡️создать новый универсальный формат - слишком долго и дорого, и не факт, что выйдет лучше и приживётся; ➡️использовать нативные форматы САПР нельзя из-за их закрытости, проблем совместимости и регуляторных ограничений. 🔹 Совмещение IFC с чертежами в других форматах. Риски: ➡️целостность данных может быть легко нарушена, если заменить лист чертежа на другой. Проверить это можно только вручную. А далее порассуждаем о конкретных способах увязки IFC и чертежей, и к чему следует стремиться. 👥 @IFC_ru 👥 @IFC_club

Как совместить IFC-модель с чертежами Проблема совместимости чертежей и модели в IFC существует давно. В идеале, ИМ ОКС как совокупность взаимосвязанных документов должна содержать непротиворечивые данные (!). Это основа основ, база. Но, к сожалению, большинство САПР не умеет выгружать в IFC всю информацию, которую IFC-файл может содержать, а IFC-вьюеры и чекеры не работают с такими файлами, ограничиваясь только 3D, свойствами элементов и структурой файла. А что же требуется? Чертежи, выполненные на базе модели, содержат: 🔴 виды (разрез, сечение, план, фасад и тд) 🔴 аннотации (выноски, марки, размеры) 🔴 таблицы (экспликации, ведомости, связанные с элементами модели) 🔴 штриховки материалов 🔴 листы, на которых все это располагается и которые являются юридически значимыми. Все это, кроме листов, поддерживает IFC, но не реализуется при выгрузке из САПР. Поэтому чекерам пока остается лишь идти по пути совмещения PDF-чертежей и видов. Об обеспечении целостности данных тут речи не идет. И если сделать плагин для САПР и выгрузить все одновременно (да еще и подписать цифровой подписью), тогда будет хоть какая-то гарантия, что чертежи и модель совместимы и не противоречат друг другу. 🔍 Разработчики BIMIT к этому прислушались и сделали плагин для Revit, который выгружает всё из списка выше. Конечно, связей элементов модели и чертежей здесь нет, зато виды/сечения размещаются в пространстве модели автоматически. Это снимает необходимость вручную измерять расстояния и позволяет сразу видеть штриховки материалов, марки и выноски. О других путях решения целостности данных еще порассуждаем. 👥 @IFC_ru 👥 @IFC_club

О новых «методических рекомендациях» крупными мазками Вышел ряд проектов приказов Минстроя, касающихся применения ТИМ. Остановимся на самом объемном документе за всю историю отечественного ТИМ-внедрения. 657 листов, и это явно не предел. 🔹 Читая название документа, ожидаешь увидеть методические рекомендации по формированию требований к ЦИМ МКД, но вместо этого внутри мы видим исключительно сами требования к моделям. Методических рекомендаций же в документе нет, хотя это обозначено в области применения. 🔹 Это значит, что стройотрасль получит еще один нормативный документ (утвержденный приказом Минстроя), наряду с СП333 и ПНСТ 909, что в результате приведет к еще большей путанице у заказчиков и исполнителей. Далее комментарии к самим требованиям: 🔹 В документе описаны цели создания моделей и наборы атрибутивных данных к ним (табл. 1, 2), но такие наборы для каждой цели избыточны. Например, для визуализации процесса строительства (№ п/п 9) нет необходимости в элемент заполнять все свойства из группы "Маркировка". То есть выбранный подход не рационален с точки зрения трудозатрат. 🔹 Не объяснено, какие элементы необходимо моделировать для каждого сценария. 🔹 Документ содержит излишний состав свойств. К примеру, элементы трубы, стр. 322:

- Этаж (RUS_ElementStoreyNumber); - Номер корпуса (RUS_ElementBuildingNumber); - Марка системы (RUS_SystemBrand); - ...

Эти данные не нуждаются в фиксации виде свойств. Потому как приведет лишь к дополнительным трудозатратам со стороны исполнителя, дублированию данных и возможным ошибкам. Эта информация «вытягивается» с помощью связей, создаваемых в IFC, и группировкой элементов в системы, зоны, и т.д. 🔹 Так называемые «карточки» элементов содержат требования к свойствам в проприетарном формате. Устанавливать это требование на федеральном уровне для всех от лица Минстроя по меньшей мере некорректно. Потому как за годы работы профсообщество накопило огромный ряд плагинов, скриптов, шаблонов проектов, библиотечных элементов, которые работают на конкретных и устоявшихся именах параметров, и за счет которых выстраиваются процессы. 🔹 Документ содержит требования, за которые исполнитель не должен отвечать: Вместе с требованиями к наборам свойств, есть еще и альтернативная группировка свойств, созданная для привязки к ним сценариев (Геометрия, Маркировка, и т.д.). Но читая документ, не становится яснее, как эта группировка реализуется в модели, и нужна ли она там. Если это невозможно, а создается в рамках ПО для анализа ЦИМ, то это не является зоной ответственности проектировщика. 🔹 Нереализуемые требования связаны со свойствами Name, Material, Description, а именно с отсутствием наборов свойств к ним. Свойств без наборов не бывает, это противоречит схеме данных. Но если здесь подразумеваются не свойства элемента, а атрибуты класса, жестко закрепленные схемой IFC, то атрибута Material у классов не существует. 🔹 В документе введены новые наборы свойств на английском языке с префиксом RusSet_, а также новые свойства тоже на английском. Какой в этом практический смысл, не объясняется. И хотя стандарт IFC не запрещает вводить новые наборы свойств, но зачем усложнять всем жизнь префиксами и английскими названиями? 🔹 не ясна логика изображения элементов в «карточках». Правильнее и информативнее изображать элементы в их минимально необходимой детализации, а не фотографией. Профильные специалисты и так прекрасно знают, как выглядят фитинги и унитазы. И в заключение. Документ местами схож с ПНСТ 909 по содержанию и смыслу, но всё же это другой документ. Стратегически правильнее было бы: 1. совместно с ДОМ.РФ и ТК505 дошлифовать ПНСТ до качественного документа; 2. апробировать его на множестве пилотных проектах, в том числе в регионах страны; 3. Провести анализ на реальную пользу от применения документа, с соответствующими выводами; 4. Дать рекомендации отечественным ПО в части реализации данных требований; 5. Выпустить итоговую редакцию в виде ГОСТ Р, не создавая альтернативу ПНСТ под видом методических рекомендаций. 📢 @ifc_ru

Гибкое создание IFC из Revit еще ближе ACCA Software анонсировала плагин usBIM.revolution для управления классами и свойствами IFC в Revit. На видео первые функции плагина, расширяющие Revit в части настройки IFC: 🔹 Гибкая и удобная настройка классификации IFC и свойств; 🔹 Копирование свойств между объектами. Скоро всё остальное. 👥 @IFC_ru 👥 @IFC_club

Друзья, теперь для обмена замечаниями и предложениями между участниками совместной работы над проектом здания в Renga или в Renga и других программах, поддерживающих IFC, можно использовать файлы в формате BCF. Такая возможность стала доступна благодаря новому плагину BCFierForRenga, появившемуся на GitHub! Формат BCF предназначен для добавления комментариев к модели, учитывая точку взгляда и видимость объектов. Передавайте BCF-файлы коллегам вместе с проектами в формате RNP или IFC, добавляйте замечания и получайте обратную связь. Вместе с BCFierForRenga совместная работа в Renga становится еще удобнее! Скачивайте и используйте! А если у вас есть предложения или замечания по работе плагина, вы можете зарегистрировать их на странице проекта на GitHub.☺️

Несколько недель назад я вела подкаст в IFC Клубе. Как ответственный человек, заранее поинтересовалась у организаторов о временном регламенте. Получила ответ, мол, не меньше 30 минут, но не больше полутора часов. И что бы вы думали? Два часа ровно. Я не специально! Просто очень хотелось рассказать подробно о нашей работе. Боюсь создать впечатление, что мы делаем что-то вроде Эврестической машины Машкина. Сейчас на YouTube опубликована запись: https://youtu.be/1TNl7O7X4Xw Большое спасибо организаторам за возможность высказаться!

Объединяйте IFC-файлы в один! IFC Suite собирает несколько файлов IFC в один благодаря функции «Merge IFC». В процессе создания объединенного файла можно: 🔹управлять объединением участков (IfcSite) в один. 🔹 собирать "здания" (IfcBuilding) в одно. 🔹 соединять этажи по имени и по отметке либо оставлять их как есть. В разработке еще несколько функций: разделение моделей, чистка, выгрузка IFC-данных и другие. А в сентябре этого года планируется выпустить бета-версию генератора IFC-модели по чертежам❗️ https://ifcsuite.inex.fr/ P.S. При использовании инструмента помните, что загружаете файлы на чужой сервер. 👥 @IFC_ru 👥 @IFC_club

✈️ Запись эфира "BIM-среда" доступна на Youtube-канале 📹 ✈️ Тема: Автоматическая экспертиза ЦИМ, мифы, реальность и перспективы ✈️ Спикер - Ольга Кутузова, продакт-менеджер направления NSR NormaCS Specification, ООО "Нанософт Разработка" ✈️ И напоследок статья Ольги: - Через тернии к… автоматической экспертизе цифровой информационной модели. @IFC_ru @IFC_club

🌐 Начинаем через 10 минут. 🔊 Тема: "Автоматическая экспертиза ЦИМ: мифы, реальность и перспективы". Присоединиться к эфиру: https://t.me/IFC_club?videochat

Ежемесячный подкаст "BIM-среда" в IFC Клубе! 🗓️ Среда, 3 июля, в 16-00 МСК 🔊 Тема: "Автоматическая экспертиза ЦИМ: мифы, реальность и перспективы" Гость: 👤 Ольга Кутузова, продакт-менеджер направления NSR NormaCS Specification, ООО "Нанософт Разработка" Поговорим о: 🛑разработках компании Нанософт в части автоматизации проверок моделей; 🛑принципах и особенностях создания цифровых требований к моделям; 🛑перспективах применения такого подхода. Присоединяйтесь! Встреча будет проходить в группе в формате видео-чата. 👥 @IFC_ru 👥 @IFC_club

С какой стороны смотреть на LODы Уровни геометрической проработки ЦИМ по СП 333.2020 отличаются от известных всем LODов, которые разрабатывал американский BIM Forum. И дело не только в обозначениях. Проблема в том, что обе эти концепции имеют определенные сложности и противоречия, и они до сих пор не могут прижиться на практике. ✈️ Может быть, стоить рассматривать LODы с другой, технической, стороны вопроса? ✈️ Предпосылки к этому читайте В СТАТЬЕ.

🔍Бесплатный IFC viewer, IDS-редактор и валидатор моделей Компания Sortdesk выпустила бета-версию IFC-просмотрщика в браузере. Преимущества: ✈️ Просмотрщик не требует установки и регистрации, всё в браузере; ✈️ Конфиденциальность прежде всего: ваши данные никогда не покидают ваш компьютер. Также есть бесплатная возможность: ✈️ загрузить модель в облако. Нужна регистрация. Если зарегистрироваться сейчас, обещают увеличить облачную квоту до 250 МБ; ✈️ создать и отредактировать IDS-требования; ✈️ проверить модель на IDS-требования; 🔥 посмотреть прямо в модели, какие объекты соответствуют требованиям, а какие нет. #IDS ifc_ru ifc_club

💣 XML-бомба, способная изменить всё! НОСТРОЙ разместил предварительный перечень XML-документов, входящих в состав ИМ ОКС по ПП 614. Разработка более 300 XML-схем планируется членами Комитета НОСТРОЙ, НОПРИЗ, членами рабочей группы по разработке XML-схем при Минстрое. 🔍 Что здесь важно: Перечень содержит XML-документы, которые могут СУЩЕСТВЕННО повлиять на процесс цифровизации отрасли. Например: - спецификации оборудования и других элементов здания; - экспликации помещений; - ведомости объемов бетона; - ведомости отделки помещений и фасадов; - и так далее. 📄 То есть все табличные данные проектной документации также планируется перевести в XML-форму. Что это дает? 🔹 Это позволит связать выгруженные спецификации с элементами модели. Реализуется это с помощью GUID элементов. 🔹 В отличие от PDF-чертежей это позволит не только просматривать, но и проверять ведомости вместе с моделью в IFC. То есть табличная часть 2D-документации обретёт цифровую форму. 🔍 Но самое главное, что для этого придется выгружать спецификации непосредственно из модели. Ведь создавать XML-документы спецификаций "руками" - занятие не из легких. Для реализации этих планов понадобится: 🔹в рамках ПО создать плагины для выгрузки этих XML из модели. При этом для корректной работы плагинов придется создавать корректные модели в стандартизованном виде; 🔹определить юридическую значимость для такого рода документов, так как на текущий момент они являются неотъемлемой частью чертежей. ✈️ Таким образом, это заставит всех полностью уйти от поднятия модели по чертежам и ручного создания спецификаций и потребует еще раз задуматься над единой моделью данных, чтобы единообразно получать необходимую информацию. P.S. Новость о данном перечне прошла еще неделю назад, но странно, что ни один BIM-паблик не обратил на это внимания. @ifc_ru @ifc_club

Что дают связи в IFC 🔹Может ли модель быть без связей между элементами? - Вполне. 🔹Поможет ли это в работе с данными в модели? - Вряд ли. Рассмотрим основные назначения связей в IFC. 🔹 Связи обеспечивают структурную целостность модели, гарантируя, что данные, связанные между собой, соответствуют семантическим правилам. Контроль целостности в свою очередь повышает достоверность информации в модели. Например, благодаря связям мы можем убедиться, что дверь действительно принадлежит стене, а не болтается сама по себе. 🔹 Связи позволяют писать сложные запросы, включающие данные из нескольких сущностей. К примеру, для элемента "Помещения" вы можете написать запрос, выдающий информацию о связанных с ним конструкциях (с помощью связи IfcRelSpaceBoundary), ограничивающих это помещение, и проверить их пожарные характеристики. 🔹 Связи обеспечивают формирование геометрии. Так, именно благодаря IfcRelVoidsElement из геометрии стены (перекрытия или иного элемента) вырезается геометрия отверстий/проемов/ниш. Т.е. изначально геометрия стены описывается без проемов, что позволяет получить у нее объем и площадь брутто, сократить число начальных полигонов, описать ее параметрически (например, осевой линией с выдавливанием). 🔹 Связи помогают избежать дублирования и избыточности данных. Например, свойства типа для элементов окна привязываются к каждому экземпляру окна при помощи отношений из набора IfcRelDefines. 🔹 Связи позволяют легко обновлять данные: меняя их в одном месте, эти изменения отразятся в связанных сущностях. Допустим, вы обновляете свойства типа о том же окне - все связанные с ним экземпляры окон будут также обновлены. Это обычный, но важный функционал САПР, о котором мы уже не задумываемся. В этом смысле добавление элементам свойств, чтобы каким-то образом обозначить связь с другим элементом или группой видится весьма сомнительным решением. К примеру, назначив помещениям "номер квартиры", при необходимости вам придется менять его в каждом помещении в составе квартиры. #База @ifc_ru

Связи в IFC Структура IFC - это не про свалку геометрии с параметрами. Как мы уже отмечали ранее, в основе лежит строгая иерархия наследуемых классов, связанных посредством отношений (или связей) и ссылок. Отношения в IFC выделены как отдельные классы (объективированы). Верхнеуровневых связей, относящихся непосредственно к родителю IfcRelationship, всего 6. Из них 5 являются родительскими абстрактными классами для множества связей-потомков. Каждое отношение может связывать объекты по следующим принципам: 🔹 "один к одному" - связь одного объекта с другим; 🔹 "один ко многим" - связь одного объекта с одним и более объектами. Многого ко многим в IFC нет. 🔍 Некоторые связи не включены в стандартизованные MVD (например, IFC4 Reference View), поэтому искать их в таких моделях нет смысла. Кроме того, часть имеющихся в стандарте IFC связей в принципе не формируется в САПР. Но это уже вопросы к ПО. ✈️ Зачем выделять связи как классы? Не проще ли упростить структуру модели и наполнять геометрию свойствами? Обратимся к официальной странице стандарта:

Объективированные связи являются предпочтительным способом обработки отношений между объектами. Это позволяет сохранить специфические свойства связи непосредственно в отношениях и в дальнейшем управлять поведением отношений.

#База @ifc_ru

🔈Опубликован видеокурс на тему: «Подготовка информационной модели к экспорту в формат IFC с учетом различных требований» 📌В рамках данной серии уроков разбирается работа с атрибутикой информационной модели в Топоматик Robur и ее оформление по различным требованиям (маппинг). Представленная в уроках информация будет полезна ТИМ-специалистам и другим лицам. В ближайшем времени данный учебный материал будет дополняться. В следующих видеороликах будут рассмотрены механизмы добавления атрибутов уровням проекта, сопоставление элементов ИМ с классами IFC, а также другие вопросы. ⤷ Смотреть видеокурс. #видео #обучение #информационное_моделирование

Топоматик Robur добавил возможность экспорта модели по схеме IFC 4х3 и IFC4. 🌐 Первый пошел. 📢 @ifc_ru 👥 @ifc_club