IfcBuildingElementProxy: как классифицировать "нестандартные" элементы и расширить классификацию IFC?

Часть 3 из 3

Итак, задача сводится к тому, чтобы в рамках схемы IFC описать объекты так, чтобы они обрели «смысл». Но слишком частое обновление IFC-схемы ради одного нового класса невозможно. Разработчики ПО не будут успевать ее соблюдать. Поэтому введены «обходные пути» в виде IfcBuildingElementProxy. А стандарт обновляется примерно раз в 5 лет.

И если элемент не вписывается в IFC-классификацию, есть несколько основных способов это поправить:

1️⃣ Использование IfcClassification - стандартный и наиболее корректный способ добавления своей классификации. Придает гибкости без нарушения стандарта, применяя любые системы: КСИ, Uniformat, МССК и другие. Но и в них может не быть подходящего класса.

2️⃣ Использование PredefinedType. Предусмотрен для «мягкого» расширения в рамках схемы. Если нужный IFC-класс и его подтип отсутствует, вводится свое значение.

PredefinedType: USERDEFINED
ObjectType: <пользовательский тип>.

Введение пользовательских типов выглядит разумно, так как не существует классификаторов, полностью подробно охватывающих все элементы.

3️⃣ Слои из CAD тоже выгружаются в IFC и могут служить для классификации.

Есть и другие, менее популярные способы, например, через стандартный атрибут Name или стандартное свойство Reference (в наборе Pset_[Entity]Common).

И немного рекомендаций:
🔹 Следует использовать IfcBuildingElementProxy в исключительных случаях и применять доп.классификацию к нему.
🔹 Договаривайтесь о принципах классификации заранее и прописывайте их в ТЗ.
🔹 И не допускайте ошибок в написании стандартных IFC-классов. Некоторые САПР имеют «защитный механизм» и автоматически экспортируют некорректный класс в IfcBuildingElementProxy. Но его все равно придется кому-то уточнять.

👥 @IFC_ru
👥 @IFC_club

IfcBuildingElementProxy: причины (зло)употребления

Часть 2 из 3

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

1️⃣ IfcProxy был введен в качестве "корзины" для любых объектов, которых нет в стандарте IFC, с возможностью их семантической идентификации через атрибут Name.

IfcBuildingElementProxy стал его эволюцией, но с уточнением, что это элемент здания. То есть он обеспечивает более строгую семантику, чем IfcProxy, поскольку четкая связь со зданием сужает его использование. (Но и этого, как правило, бывает недостаточно на практике).

Тем не менее, устоялось ошибочное представление, что IfcBuildingElementProxy - это любой объект, который не описан стандартом, но это не так.

2️⃣ Всегда проще не искать нужный класс, а экспортировать "как есть" вместо настройки сопоставлений.
Часто это происходит из-за непроработанного ТЗ на модель либо его поверхностного исполнения.

Если ТЗ не содержит конкретных указаний, какую классификацию следует применять, то результат предсказуем.

3️⃣ Некоторые ПО просто не умеют выгружать ни во что другое (например, старый экспортер из Civil). То есть синтаксически файл IFC корректен, но семантически это не соответствует стандарту, и данные в модели теряют смысл. Для переопределения классов приходится использовать специализированные инструменты вроде Bonsai или FreeCAD.

Что делать? - об этом в третьей части.

👥 @IFC_ru
👥 @IFC_club

IfcBuildingElementProxy: удобный костыль или скрытая проблема?

Часть 1 из 3

Давно хотелось написать про IfcBuildingElementProxy (а также IfcProxy для версий до IFC4x1). Он часто используется, когда в IFC-стандарте не удается найти подходящий класс. Но загвоздка в том, что его бесконтрольное применение может создать больше проблем, чем решить их.

Чем грозит такое использование IfcBuildingElementProxy для классификации элемента?

➡️ Потеря семантики - элемент становится "черным ящиком". Он лишается своего назначения, если proxy-класс применяется без дополнительной классификации. А это нарушает принципы информационного моделирования и не совсем вписывается логику онтологии IFC.

➡️ Проблемы для коллег. То есть по сути перекладывание задачи классификации на кого-то позднее, кто будет вынужден вручную разбираться, что же скрывается за такими Proxy-элементами.

Оставлять Proxy-элементы в таком виде - плохая практика.

Но почему так происходит и что делать? - разберемся в следующих частях.

👥 @IFC_ru
👥 @IFC_club

ИИ-классификация элементов на основе геометрии в Qonic

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

Кроме того, Qonic умеет редактировать геометрию, исправлять классы, добавлять/править свойства элементов и сохранять в IFC.

👥 @IFC_ru
👥 @IFC_club

Сегодня завершился десятый (!) курс по технологиям информационного моделирования.

Спасибо всем, кто был с нами: «Росатому» и другим организациям за неудобные вопросы, споры и за то, что делились своим опытом. Для нас курс стал еще одной ступенькой в развитии.

Мы старались сделать курс максимально честным и детальным: разобрали BIM-подходы в мировом контексте, в российской практике, в экспертизе и даже в узких отраслевых нюансах. От Градкодекса до коллизий в IFC.

С 2021 года курс прилично «прокачался»:
🔹 добавили больше материала про работу с IFC и создание цифровых требований;
🔹 сместились акценты в сторону работы с заказчиком и правильному составлению ТЗ на модель.

Особая благодарность Ольге Кутузовой (@Kutuzova_O, NSR-Specification) и Николаю Самопалу (@NS_BIM, Wizardsoft) - на ваших лекциях мы тоже учимся.

👥 @IFC_ru
👥 @IFC_club

Начинаем новую рубрику:
Проверь себя в 🌐IFC

🕙 Один вопрос каждую пятницу в 10:00

✈️ Запись эфира "Без права на ошибку: Транспортная инфраструктура в IFC"

✈️ Гость: Филипп Сергеев, руководитель MARKS DIGITAL, заместитель генерального директора по цифровым технологиям MARKS GROUP

📹Youtube | 📺Rutube | ✈️ Telegram

👥 @IFC_ru
👥 @IFC_club

Что нового в Revit 2026 в части IFC

1️⃣ Теперь можно выбирать способ координационной привязки для связанных IFC-файлов. Они могут располагаться по внутреннему началу, базовой точке проекта или точке съемки.

2️⃣ На этом всё )

UPD. Остальные мелкие улучшения в комментах.

👥 @IFC_ru
👥 @IFC_club

Проект приказа Минстроя о составе ЦИМ в IDS!

На публичное обсуждение размещен проект приказа Минстроя России об утверждении состава ЦИМ на этапе проектирования.

И многие уже успели его обсудить. Но мы решили на этом не останавливаться и сделали по этому проекту IDS-требования (по таблице 1).

Помимо того, что проект приказа требует изменений в формулировках, также нужны уточнения в самих таблицах.

Так, для элементов инженерных систем введены слишком обобщенные понятия (например, «Оборудование»). В результате не совсем понятно, что конкретно в них входит.

С точки зрения целей применимости ЦИМ на этапе проектирования к проекту приказа есть вопросы, но в техническом плане он вполне выполним (после ряда доработок).

👥 @IFC_ru
👥 @IFC_club

Ежемесячный подкаст "BIM-среда" в IFC Клубе!

В группе мы часто репостим классные кейсы с канала MARKS DIGITAL. Коллеги хорошо продвинулись в использовании разных ПО. В эту среду автор канала у нас в гостях!

🗓️ Среда, 2 апреля, в 16-00 МСК

🔊 Тема: "Без права на ошибку: Транспортная инфраструктура в IFC"

Гость:
👤 Филипп Сергеев, Руководитель MARKS DIGITAL, заместитель генерального директора по цифровым технологиям MARKS GROUP

Поговорим о:
🛑особенностях проектирования объектов инфраструктуры;
🛑опыте прохождения экспертиз с моделями в IFC 👀;
🛑экспорте в IFC из Rhino;
🛑применении Bonsai / BlenderBIM для решения нетривиальных задач по доработке IFC-файлов ⚡️;
🛑использовании BCF для обмена замечаниями;
🛑проверках модели по IDS-требованиям без bonsai;
🛑и много другом!

Присоединяйтесь!
Встреча будет проходить в группе в формате видео-чата.

👥 @IFC_ru
👥 @IFC_club

Провели встречу с замечательным человеком, BIM-лидером отрасли в части инфраструктуры Аллой Землянской (Tangl).
Обсудили перспективы открытых стандартов передачи данных в отечественных ПО.

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

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

🔹Также поговорили о передаче отчетов о коллизиях в BCF. Востребованность формата пока по большей части ограничивается госсектором и органами экспертиз. Но при обмене замечаниями через BCF-сервер, популярность его будет только расти. И такие разработки в России уже ведутся.

🔹И затронули перспективу перехода к IFC4x3, как более проработанному и развитому в части описания инфраструктурных объектов.

👥 @IFC_ru
👥 @IFC_club

Альтернативная классификация

Не хватает классов IFC?

🔍 Использование инструментов That Open Engine и JavaScript (для красоты) позволяет добавлять, редактировать и сохранять дополнительную классификацию к элементам, будь то КСИ, МССК, Uniformat, OmniClass или любую другую.

Классификационных систем в одном IFC-файле может быть несколько, в зависимости от задач.

Для кода и наименования классификатора предназначены специальные сущности IfcClassificationReference и IfcClassification. Это важно, чтобы классификатор всегда находился в одном месте, а не в произвольном параметре вроде "код по КСИ".

✈️ Напомним, что в редакторе IDS от ИСП РАН можно создавать требования с использованием альтернативной классификации (КСИ, РЖД, МССК).

👥 @IFC_ru
👥 @IFC_club

Интероперабельность. Роль заказчика и разработчика ПО

Добавим немного мыслей к цитатам из поста Дмитрия Чубрика об интероперабельности.

Важность открытых форматов большинство заказчиков осознало несколько лет назад, когда Autodesk ушел

Это осознали только те, кто давно работает с BIM. Сегодня заказчики, особенно государственные - это наиболее "просевшее" звено. И связано это с тем, что они до сих пор не могут сформулировать свои потребности, исходя из которых формулировались бы требования.

Заказчик должен играть ключевую роль в установлении требований к данным. Однако сегодня мы имеем немного другую ситуацию:

- BIM-стандарты и ТЗ на модель зачастую пишут сами проектировщики;
- требования к форматам и классификации - в постановлениях Правительства;
- а проверки на коллизии - дело экспертизы.

Заказчик в этом процессе как-то затерялся.

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

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

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

👥 @IFC_ru
👥 @IFC_club

Машинно-интерпретируемые требования: иллюзия или реальность?

Рассмотрим схему:

1. Определили цифровые требования в IDS.
2. Создали модель в IFC.
3. Сформировали отчет об ошибках в BCF.
4. Отправили данные через openCDE.

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

На этой картинке нас смущает пункт 3 и отсутствие еще одного важного шага между 2 и 3.

🔍 Отчет в BCF - это не проверка, а лишь отчет о проверке.

Это не check, а report. И в этом кроется ключевая ошибка. Где же сам механизм проверки? Где открытые алгоритмы, которые должны лежать в основе этой системы?

Что мы имеем на текущий момент:

🛑 IDS-стандарт и его дальнейшее развитие призвано формализовать требования к информации в машинном виде.
При этом алгоритмы проверки файла на соответствие IDS находится вне файла требований, а на стороне вьюверов и чекеров.

Вопрос "подкапотной обработки" модели на соответствие требованиям решают OpenSource-проекты, наиболее известный из них - IfcOpenShell.

🛑 В России формируется реестр требований, который к 2026 году планируют перевести в машинно-интерпретируемую форму, использовав для этого разметку на базе КСИ.
При этом мы не видим ни активного движения в сторону апробации формируемых требований, ни верификационных примеров, ни открытых алгоритмов, которые бы помогли другим разработчикам ЕДИНООБРАЗНО интерпретировать и проводить проверку.

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

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

🔍Представьте масштаб работы:
Создателям реестра предстоит не только описать требования, но и разработать, протестировать и внедрить алгоритмы проверки. Это приличный пласт работы, требующий больших усилий.

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

✈️ Ну и вопрос "на засыпку", готовы ли мы к такому уровню цифровизации? Или нам еще рано говорить о полной автоматизации проверок?

📢 @IFC_ru
👥 @IFC_club

Обзор библиотек для просмотра IFC в веб-приложениях

Если вы планируете создавать веб-приложения для работы с моделями, важно не ошибиться с подходящей библиотекой для отображения IFC-файлов.

Коллеги из MARKS DIGITAL сделали подробный разбор популярных решений:

🔹Ifc.js (в настоящий момент развивается как That Open Company);
🔹Xbim;
🔹Xeokit.

Каждая библиотека имеет свои особенности, выбор зависит от задач проекта.

Подробнее в статье: читать

👥 @IFC_ru
👥 @IFC_club

Тестируем выгрузку стен из Revit

Зачастую в проектах можно встретить два класса стен: IfcWall и IfcWallStandardCase. Обычно пользователь не назначает второй класс. Но он появляется "сам собой". Это связано с особенностями выгрузки из Revit в схему IFC2x3. Разберемся с этим.

Что говорит стандарт:

🔹 IfcWallStandardCase - класс для стен с набором слоев материала, представленных выдавливанием (SweptSolid) с постоянной толщиной вдоль траектории.

🔹 IfcWall - класс для стен с переменной толщиной, сложными сечениями или геометрией, которые не могут быть просто выдавлены.

Начиная с IFC4 сущность IfcWallStandardCase убрали, и всем стенам назначается IfcWall.

Как с этим справляется Revit?

Наш тест показал, что Revit 2021 и 2024 выгружает в IFC2x3 CoordanationView2.0 с особенностями и ошибками геометрии в обеих версиях ревита и назначением классов IfcWall только для стен, имеющих нестандартную геометрию (с врезками плит, с наклоном и т.д) .

При этом выгрузка в IFC4 ReferenceView постепенно улучшается. 24-ый ревит справился с выгрузкой без ошибок, при этом 21 версия имеет проблемы с геометрией наклонных стен.

Ранее мы писали мнение о IFC 2x3.

Наш вердикт:
Выгружаем стены в IFC4 и выше, используем новый ревит со свежим экспортером.

👥 @IFC_ru
👥 @IFC_club

Связи BIM-стандартов ISO

Комитет по моделированию и стандартам EC3 связал воедино все ISO-стандарты по информационным технологиям в строительстве.

Стандарты отбираются фильтрами. А при нажатии на кнопку Relationships отображаются все связи между этими стандартами.

Полезный и нужный труд.

https://ec-3.org/BIM-Standards-Landscape-Explorer.html

👥 @IFC_ru
👥 @IFC_club

Проверка IFC моделей по требованиям IDS

На Хабре вышла хорошая обзорная статья от Ильи Савельева по работе с IDS-требованиями, с полезными ссылками и практическими кейсами на Python и библиотеки ifcopenshell.

Добавляем в закладки.

👥 @IFC_ru
👥 @IFC_club

Как подружить элементы и документы в IFC

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

Ранее мы публиковали новость о том, что в BIM Vision появилась эта возможность.

Создавать такие ссылки можно с помощью инструментов от That Open. Пара видео 🎞тут.

🔍Это очень важный функционал, поскольку он позволяет рассматривать модель не как придаток к комплекту документации, а как главный источник структурированной информации по проекту.

🔍То есть стандарт IFC позволяет формировать "скелет" для интеграции геометрических данных, буквенно-цифровой информации и документации (в соответствии с ISO 19650 и ISO 7817).

👥 @IFC_ru
👥 @IFC_club

DeepSeek и IFC. Пример запроса

Запрос:
Сопоставь работу со схемой данных стандарта IFC.
Используй только данные с ресурса https://standards.buildingsmart.org/IFC/RELEASE/IFC4_3/

Устройство железобетонных колонн в деревянной опалубке высотой:до 6 м, периметром более 4 м

Ответ:
Для сопоставления работы "Устройство железобетонных колонн в деревянной опалубке высотой: до 6 м, периметром более 4 м" со схемой данных стандарта IFC (Industry Foundation Classes) версии IFC4_3, необходимо определить соответствующие классы и атрибуты, которые описывают процесс строительства железобетонных колонн с использованием деревянной опалубки.

Шаги для сопоставления:
Описание колонны:

Железобетонная колонна может быть описана с использованием класса IfcColumn, который представляет собой вертикальный строительный элемент.

Атрибуты:

Name: "Железобетонная колонна".

PredefinedType: COLUMN.

Height: 6 м (может быть указано в IfcPropertySingleValue).

Perimeter: более 4 м (также может быть указано в IfcPropertySingleValue).

Материал колонны:

Железобетон может быть описан с использованием класса IfcMaterial с атрибутом Name = "Железобетон".

Для уточнения свойств материала (например, марка бетона, класс арматуры) можно использовать IfcMaterialProperties.

Опалубка:

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

Атрибуты:

Name: "Деревянная опалубка".

PredefinedType: FORMWORK.

Процесс устройства колонн:

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

Атрибуты:

Name: "Устройство железобетонных колонн в деревянной опалубке".

OperatesOn: ссылки на колонну (IfcColumn) и опалубку (IfcConstructionMaterialResource).

➕
В схеме IFC нет стандартного «периметра» для колонны, поэтому DeepSeek предложил пользовательское свойство Perimeter.

В случае с высотой DeepSeek не определил стандартный количественный показатель (quantity) Length как высоту колонны и также предложил ввести свойство Height.

✈️ Запись эфира "OpenSource, IFC и IDS в управлении проектами"

✈️ Гость: Антон Мотовилов, руководитель отдела цифровизации и технологий информационного моделирования, ООО «Желдорпроект»

📹Youtube | 📺Rutube | ✈️Презентация

👥 @IFC_ru
👥 @IFC_club

Как посмотреть структуру IFC-файла

🛑 GeometryGym IFC Tree Viewer (скрин 1) - легкий и быстрый просмотрщик "дерева" IFC-файла с показом наименования атрибутов.

🛑 IfcQuickViewer (скрин 2) - еще один простой и надежный просмотрщик структуры IFC-файлов, которому уже более 20 лет. С его помощью можно отследить связи элемента с другими.

🛑 KITModelViewer (скрин 3) - мощный, но порой вылетающий, немецкий вьюер. Плюсом является то, что можно увидеть STEP-структуру элемента вместе с иерархией, геометрией, свойствами и связями.

🛑 Open IFC Viewer (скрин 4) - недоступный без VPN вьюер от ODA с хорошим функционалом по просмотру структуры файла.

Ну и конечно же старый добрый Notepad++ с предварительной настройкой подсветки IFC-синтаксиса. Без подсветки совсем грустно.

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

👥 @IFC_ru
👥 @IFC_club

Ежемесячный подкаст "BIM-среда" в IFC Клубе!

Помните крутой доклад на BIM-форуме про BIM-менеджмент и IDS? В эту среду мы поговорим подробнее, что к чему и почему.

🗓️ Среда, 5 февраля, в 16-00 МСК

🔊 Тема: "OpenSource, IFC и IDS в управлении проектами"

Гость:
👤 Антон Мотовилов, Руководитель отдела цифровизации и технологий информационного моделирования, ООО «Желдорпроект»

Поговорим о:
🛑управлении процессами по информационному моделированию с помощью инструментов на открытом исходном коде;
🛑управлении требованиями к IFC-моделям с использованием OpenSource-решений;
🛑разработках в части автоматизации проверок моделей;
🛑и перспективах применения такого подхода.

Присоединяйтесь!
Встреча будет проходить в группе в формате видео-чата.

👥 @IFC_ru
👥 @IFC_club

Bonsai - еще не САПР, но больше, чем САПР

В то время, как бесплатный ИИ-помощник DeepSeek уложил на лопатки IT-гигантов, вернемся в более приземленное русло.

Новые инструменты на основе принципов открытости могут заявить о себе очень быстро. И BIM-моделирование - не исключение.

У нас нет завышенных ожиданий по поводу Bonsai, однако считаем, что этот инструмент заслуживает в IFC Клубе отдельной ветки Bonsai | BlenderBIM.

➖Конечно, надстройку Bonsai на базе мощного бесплатного ПО Blender нельзя назвать полноценным САПР.

✅Вместе с тем его возможности выходят за рамки обычного IFC-вьюера и традиционных САПР.

Что в нем стоит обсудить:

🔹 Обнаружение коллизий и работа по их устранению на базе BCF
🔹 Создание новых IFC-моделей с нуля и редактирование существующих
🔹 Создание 2D-документации
🔹 Исправление некорректной координационной привязки файлов IFC
🔹 Создание календарных графиков и их визуализации
🔹 Интеграция c bSDD для подключения альтернативной классификации
🔹 Перевод моделей между различными версиями IFC (например, IFC4 в IFC4x3)
🔹 Использование библиотек IFC для повторного применения
🔹 Валидация моделей на соответствие цифровым требованиям IDS
🔹 Извлечение необходимых данных
🔹 Назначение наборов свойств (Psets) для объектов
🔹 и многое другое.