BIM-форум: поговорим про чертежи и модели

Завтра приму участие в Круглом столе «ЦИМ как отказ от чертежей: все «за» и все «против».

Тема стара как мир, но вновь и вновь всплывает в BIM-среде. Для нее были поводы и у нас на канале:

🟡 XML-бомба, способная изменить всё!
🔵 BIM-среда: «Экспертиза без чертежей: ожидания и реальность» (гость: Сергей Сербин) и наше мнение о пилоте
🟣 Как совместить модель в IFC с чертежами
🔴 Связка IFC и чертежей: проблема целостности данных
🟢 Способы связки чертежей и модели в IFC

Завтра обсудим эту важную и сложную тему с разных сторон. До встречи!

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

На прошедшем XI BIM-Форуме команда Института системного программирования РАН представила технологический стек, меняющий подход к цифровой нормативной базе. Их цель - это полная автоматизация цепочки:

НОРМАТИВ (текст) ➡️ OWL-ОНТОЛОГИЯ ➡️ SPARQL/SWRL-ПРАВИЛА ➡️ IDS++ ➡️ АВТОПРОВЕРКА IFC

Текст нормативов предлагается сначала переводить в виде OWL-онтологии (машинопонятный "словарь"). Далее с помощью SPARQL (язык запросов) и SWRL (язык логических правил) они трансформируются в спецификации IDS/IDS++ для проверки IFC-моделей.

Таким образом, от пункта норматива появляется сквозная прослеживаемость к правилу SWRL, его формализованному представлению в IDS++ и далее (после валидации) к замечанию в BCF. Важно, что система будет проводить семантическую проверку, то есть "понимать" и обращаться не только к атрибутам модели, но и контексту, отношениям и геометрии.

Это не ещё один плагин, а создание формальных знаний для строительной отрасли. Фундаментальный подход, где конечным продуктом являются готовые стандартизированные IDS-файлы для повседневной практической проверки данных в IFC.

👥 @IFC_ru
👥 @IFC_club

Предновогодний прогон всех постов канала через ИИ (+статистика от TGStat)

В дополнение к статистике от ТGStat пропустили через ИИ все посты нашего канала. И вот что он сказал:

В лидерах по темам в 2025 году оказались:
1. Цифровые требования (IDS) и их развитие – 14 постов
2. Критика и разбор нормативных документов – 11 постов и упоминаний
3. Разбор ТЗ на ЦИМ (серия постов) – 10 постов и упоминаний
4. Инструменты для работы с IFC – 9 постов и упоминаний
5. IFC-структура, классы и связи – 8 постов
6. Интеграция ИИ и IFC – 7 постов
7. OpenBIM и открытые стандарты – 6 постов
8. Связь чертежей и IFC-моделей – 5 постов и упоминаний
9. Обучение и курсы – 4 поста
10. Инфраструктурные объекты и IFC – 4 поста
11. Прочие темы – 5 постов

💻 Самый популярный пост 💻

Вывод от ИИ:

2025 год стал годом цифровых требований (IDS) и глубокого анализа нормативной базы. Канал активно продвигал переход от «бумажных» стандартов к машиночитаемым форматам, критиковал противоречия в документах Минстроя и показывал практические инструменты для работы с IFC.

Главный месседж канала 2025 года по версии DeepSeek:

«IFC — это не просто формат обмена геометрией, а онтология для управления данными на всём жизненном цикле. Цифровые требования (IDS) и открытые стандарты — основа цифровой зрелости отрасли.»

Всех с Наступающим!

🎄 @IFC_ru
🎄 @IFC_club

СОДЕРЖАНИЕ 2025

1. Проблемы излишней стандартизации имен файлов моделей
2. "Формат RVT - это де-факто стандарт отрасли"
3. Bonsai - еще не САПР, но больше, чем САПР
4. Как посмотреть структуру IFC-файла
5. DeepSeek и IFC. Пример запроса
6. Как подружить элементы и документы в IFC
7. Проверка IFC моделей по требованиям IDS (статья)
8. Связи BIM-стандартов ISO
9. Тестируем выгрузку стен из Revit
10. Обзор библиотек для просмотра IFC в веб-приложениях
11. Машинно-интерпретируемые требования: иллюзия или реальность?
12. Интероперабельность. Роль заказчика и разработчика ПО
13. Альтернативная классификация. Что делать, если не хватает классов IFC?
14. Встреча с Аллой Землянской. О цифровых требованиях IDS
15. Проект приказа Минстроя о составе ЦИМ в IDS
16. Что нового в Revit 2026 в части IFC
17. Завершился 10-ый курс по ТИМ
18. ИИ-классификация элементов на основе геометрии в Qonic
19. IfcBuildingElementProxy: удобный костыль или скрытая проблема?
20. IfcBuildingElementProxy: причины (зло)употребления
21. IfcBuildingElementProxy: как классифицировать элементы и расширить классификацию
22. 7D Modeler 1.5: новый релиз!
23. Список MVD для IFC4x3 дополнен
24. О новых типах объектов в IFC4x3
25. Открытый веб-валидатор IFC
26. 10 шагов по созданию корпоративного стандарта на базе IFC
27. О вариантах структуры IFC-проекта
28. Автоматизированный перевод IDS-требований в атрибуты ЦИМ
29. Топоматик 360 с крутыми возможностями!
30. Разбираем ТЗ на ЦИМ - 1. О классификации
31. Разбираем ТЗ на ЦИМ - 2. О делении модели на разделы
32. 1-ое место в ТИМ-лидерах!
33. О делении составных элементов на части
34. Разбираем ТЗ на ЦИМ - 3. Об информационном наполнении элементов
35. Разбираем ТЗ на ЦИМ - 4. О несоответствии атрибутивного состава целям моделирования
36. 1000 подписчиков!
37. Всё, что нужно знать про IFC5
38. Разбираем ТЗ на ЦИМ - 5. Проблема LOD
39. ПНСТ 909-2024 "Жилые здания" в IDS!
40. Разбираем ТЗ на ЦИМ - 6. О матрице коллизий
41. Цикл постов с разборами ТЗ на ЦИМ
42. Еще раз о проекте приказа Минстроя о составе ЦИМ (презентация)
43. Выгрузка в IFC из Revit. Без Revit
44. Структура в инфраструктуре
45. Атрибутивка из требований прямо в IFC - это реально. Без нативных форматов
46. Как совместить IFC-модель с чертежами
47. Связка IFC и чертежей: проблема целостности данных
48. IfcCheckingTool_Lite - инструмент проверки семантической и синтаксической корректности IFC
49. Способы связки чертежей с моделями в IFC
50. Ежегодный форум РосТИМ 2025
51. Перевод реестра требований в цифровой вид. Презентация ИСП РАН
52. Предновогодний анализ постов через ИИ

Проверь себя в IFC:
Вопрос №1
Вопрос №2
Вопрос №3
Вопрос №4
Вопрос №5
Вопрос №6
Вопрос №7
Вопрос №8
Вопрос №9
Вопрос №10
Вопрос №11
Вопрос №12
Вопрос №13
Вопрос №14

Подкасты "BIM-среда" на Youtube 📹 | Rutube 📺

👥 @IFC_ru
👥 @IFC_club

СОДЕРЖАНИЕ 2026 (обновляется)

1. Коллизии. Новый взгляд? + иерархия коллизий
2. Коллизии. Новый взгляд? Дополнение.
3.
4.
5.
6.
7.

Подкасты "BIM-среда" на Youtube 📹 | Rutube 📺

👥 @IFC_ru
👥 @IFC_club

Коллизии. Новый взгляд?

Продолжаем тему коллизий. Сегодня сложилось обывательское убеждение, что «проверка на коллизии» - это про геометрические пересечения.

А во времена BIM-стандартов от вендоров предлагалось что-то странное: жесткие коллизии, мягкие, газообразные… Это аналогично 4D, 5D, 6D, 7D. Проблема в том, что пока не посмотришь, что это значит, не поймешь, о чем речь. В результате - недопонимание и проблемы в коммуникации.

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

🔍 В приложенном ниже файле я предложил структуру типов коллизий/дефектов, выявляемых в результате верификации и валидации. Коллизии представлены шире, чем только геометрические. На истину не претендую, просто предложение.

🔹 При верификации выявляются дефекты в синтаксисе и семантике набора данных (файла IFC, XML-документа и т.д.). Например, в IFC-файле обнаружен GUID, начинающий с буквы, хотя по правилам в IFC он должен начинаться с цифры.
🔹 При валидации проверяем данные на различные семантические требования (в том числе высокого уровня: нормативные требования).

Это лишь набросок, но такое деление добавит системности и в перспективе не позволит упустить ни одну категорию проверок и будет основой для дальнейшей автоматизации.

👥 @IFC_ru
👥 @IFC_club

Коллизии. Новый взгляд? (Дополнение)

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

Кстати, он принципиально отличается от того, что предлагается в ЕСИМ, где дефекты подразделяются на:
🔴 устранимые и неустранимые (по возможности исправления);
🔴 скрытые и явные (по вероятности/сложности обнаружения);
🔴 критические и некритические (по приоритету).

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

То есть оба подхода могут друг друга хорошо дополнить.

1️⃣ Структура по типам коллизий даст удобную навигацию и поможет найти источник проблемы, а также назначить исполнителя.
2️⃣ Оценка риска дефекта позволит понять последствия и вовремя предпринять нужные решения.

👥 @IFC_ru
👥 @IFC_club

О методическом пособии по созданию цифровых требований (часть 1/2)

"НИЦ ЦПС" по заказу ФАУ "ФЦС" разработал методическое пособие по созданию цифровых требований для проверки ЦИМ. Мы не можем пройти мимо этого документа, так как направляли в ФАУ "ФЦС" наши комментарии по нему, но они остались без ответа. Проанализируем документ и обозначим некоторые вопросы.

Сразу обозначим, что создавать формат для требований без привязки к формализованной схеме данных - это как писать правила дорожного движения, не зная, какие бывают машины, дороги и знаки. Здесь предполагается ввести свой «язык» описания проверок, игнорируя тот факт, что модели уже давно представляются по стандарту IFC (ГОСТ Р 10.0.02-2019).

К чему это приведёт на практике?

🔴 Семантический разрыв. Требования будут описывать одни сущности и связи, а данные в IFC-модели будут содержать другие. Глухой телефон.

🔴 Эпоха коннекторов. Вместо следования единому стандарту каждой системе автоматизированной проверки придется писать собственный "переводчик" с языка методики. Это приведет к двойным трудозатратам для всех: и для составителей требований, и для разработчиков ПО.

🔴 Методика делает ставку исключительно на КСИ. Но строительная отрасль им не ограничивается: используются МССК, отраслевые классификаторы РЖД и т.д. Привязка только к КСИ не только игнорирует это, но и делает всю систему заложником его частых обновлений (4+ раза в год!): все созданные ранее правила проверок придется постоянно актуализировать из-за возможной смены кодов.

🔴 Игнорирование IFC. Самое тревожное - подход заточен только под проверку атрибутов ("параметров"). Он игнорирует мощь объектно-ориентированной модели IFC как онтологии: типизированные связи, наследование свойств - не слышали?

Скатываясь к примитивному способу проверок, их ценность просто потеряется. И тогда зачем это всё?

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

Далее напишем - как попытаться всё поправить.

@IFC_ru
@IFC_club

О методическом пособии по созданию цифровых требований: как исправить проблемы (часть 2/2)

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

Порассуждаем над конкретными шагами, как исправить ситуацию:

🛑 Устранить семантический разрыв. Не вводить новый формат, а надстраиваться над тем, что есть. Для этого надо признать, наконец, IFC основным стандартом представления данных и создать надстройку. А надстройка - это IDS, работающий инструмент для описания описания проверок. Он уже живёт, развивается, под него пишут функционал. Его можно и нужно дорабатывать. Синхронизироваться с мировым опытом и национальными разработками в рамках ТК 505, а не загонять самих себя в технологическую изоляцию. Также не мешало бы скоординировать работу с разработчиками национального расширения IDS-стандарта.

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

🛑 Использовать стандартные свойства IFC и всю его мощь как онтологии. На первом этапе вместо введения тысяч новых полей - разработать таблицу мэппинга произвольных свойств требований к стандартным наборам IFC (Pset_ и Qto_). Хотите проверять "Предел огнестойкости"? Сопоставьте это требование со стандартным свойством FireRating из Pset_WallCommon. На следующем этапе - начинать работать со связями.

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

Кратко:
- IFC - как базовый фундамент;
- механизм классификационных ссылок для гибкости;
- таблицы мэппинга свойств и использование связей IFC;
- развитие IDS.

👥 @IFC_ru
👥 @IFC_club