Всё про IFC

Требования к ЦИМ в формате IDS от Мособлэкспертизы Мособлэкспертиза разработала новую редакцию требований к ЦИМ, в том числе в формате IDS: - Требования к ЦИМ автомобильных дорог и улично-дорожной сети. - Требования к ЦИМ наружных инженерных сетей. - Требования к ЦИМ производственным и непроизводственным ОКС. > СКАЧАТЬ < @IFC_ru @IFC_club

А вот интересное: из вот этого видео: https://www.youtube.com/watch?v=Ksz-9552gKY (канал крайне рекомендую, автор использует FreeCAD в около-IFC темах) узнал про вот этот визуальный редактор IDS: https://www.idsedit.com/ Пара но: • Ссылка открылась только из-под ВПН; • Как и бывает с подобными визуальными редакторами, с более-менее серьёзной спецификацией (IDS СПб ГАУ ЦГЭ (Конструктивные решения).ids, например) уже неудобно.

О методическом пособии по созданию цифровых требований: как исправить проблемы (часть 2/2) Попробуем предложить решения проблемы. Важность создания методики мы не будем отрицать, но надо подумать над интеграционным фундаментом, когда бы нас понимали все, а не только в рамках данной методики. Порассуждаем над конкретными шагами, как исправить ситуацию: 🛑 Устранить семантический разрыв. Не вводить новый формат, а надстраиваться над тем, что есть. Для этого надо признать, наконец, IFC основным стандартом представления данных и создать надстройку. А надстройка - это IDS, работающий инструмент для описания описания проверок. Он уже живёт, развивается, под него пишут функционал. Его можно и нужно дорабатывать. Синхронизироваться с мировым опытом и национальными разработками в рамках ТК 505, а не загонять самих себя в технологическую изоляцию. Также не мешало бы скоординировать работу с разработчиками национального расширения IDS-стандарта. 🛑 Не описывать сущности в требованиях кодами по КСИ. КСИ - важный справочник, но его коды не должны жестко вшиваться в структуру требований. В IFC есть механизм, присваивать элементам классификационную ссылку через IfcClassification и IfcClassificationReference. Это позволяет гибко использовать КСИ и любой другой классификатор одновременно, без переписывания правил. 🛑 Использовать стандартные свойства IFC и всю его мощь как онтологии. На первом этапе вместо введения тысяч новых полей - разработать таблицу мэппинга произвольных свойств требований к стандартным наборам IFC (Pset_ и Qto_). Хотите проверять "Предел огнестойкости"? Сопоставьте это требование со стандартным свойством FireRating из Pset_WallCommon. На следующем этапе - начинать работать со связями. Предлагаемый путь - это переход от создания "ещё одного формата" к интеграции методики в существующую онтологию данных строительной отрасли, описанную в IFC. Это снимет ряд технических противоречий, устранит двойные трудозатраты и, главное, даст на выходе практический инструмент для сложных междисциплинарных проверок. Кратко: - IFC - как базовый фундамент; - механизм классификационных ссылок для гибкости; - таблицы мэппинга свойств и использование связей IFC; - развитие IDS. 👥 @IFC_ru 👥 @IFC_club

О методическом пособии по созданию цифровых требований (часть 1/2) "НИЦ ЦПС" по заказу ФАУ "ФЦС" разработал методическое пособие по созданию цифровых требований для проверки ЦИМ. Мы не можем пройти мимо этого документа, так как направляли в ФАУ "ФЦС" наши комментарии по нему, но они остались без ответа. Проанализируем документ и обозначим некоторые вопросы. Сразу обозначим, что создавать формат для требований без привязки к формализованной схеме данных - это как писать правила дорожного движения, не зная, какие бывают машины, дороги и знаки. Здесь предполагается ввести свой «язык» описания проверок, игнорируя тот факт, что модели уже давно представляются по стандарту IFC (ГОСТ Р 10.0.02-2019). К чему это приведёт на практике? 🔴 Семантический разрыв. Требования будут описывать одни сущности и связи, а данные в IFC-модели будут содержать другие. Глухой телефон. 🔴 Эпоха коннекторов. Вместо следования единому стандарту каждой системе автоматизированной проверки придется писать собственный "переводчик" с языка методики. Это приведет к двойным трудозатратам для всех: и для составителей требований, и для разработчиков ПО. 🔴 Методика делает ставку исключительно на КСИ. Но строительная отрасль им не ограничивается: используются МССК, отраслевые классификаторы РЖД и т.д. Привязка только к КСИ не только игнорирует это, но и делает всю систему заложником его частых обновлений (4+ раза в год!): все созданные ранее правила проверок придется постоянно актуализировать из-за возможной смены кодов. 🔴 Игнорирование IFC. Самое тревожное - подход заточен только под проверку атрибутов ("параметров"). Он игнорирует мощь объектно-ориентированной модели IFC как онтологии: типизированные связи, наследование свойств - не слышали? Скатываясь к примитивному способу проверок, их ценность просто потеряется. И тогда зачем это всё? Создавать изолированный язык для проверок - это методологический тупик. Мы рискуем получить стройный, но, к сожалению, бесполезный реестр требований. Проверка моделей на эти требования не будет иметь большой значимости и смысла. Далее напишем - как попытаться всё поправить. @IFC_ru @IFC_club

Коллизии. Новый взгляд? (Дополнение) Над предложенным выше делением коллизий еще стоить поработать, но здесь важен сам подход. Кстати, он принципиально отличается от того, что предлагается в ЕСИМ, где дефекты подразделяются на: 🔴 устранимые и неустранимые (по возможности исправления); 🔴 скрытые и явные (по вероятности/сложности обнаружения); 🔴 критические и некритические (по приоритету). Подход ЕСИМ лежит в другой плоскости. И это никакая не классификация по типам коллизий (как нас уверяют разработчики стандартов), а их статусы, так как эти характеристики подойдут предложенных нами типов. Но с ними можно согласиться и даже расширить, так как с их помощью можно будет определять уровень риска коллизии. А это может улучшить практику управления проектом. То есть оба подхода могут друг друга хорошо дополнить. 1️⃣ Структура по типам коллизий даст удобную навигацию и поможет найти источник проблемы, а также назначить исполнителя. 2️⃣ Оценка риска дефекта позволит понять последствия и вовремя предпринять нужные решения. 👥 @IFC_ru 👥 @IFC_club

Коллизии. Новый взгляд? Продолжаем тему коллизий. Сегодня сложилось обывательское убеждение, что «проверка на коллизии» - это про геометрические пересечения. А во времена BIM-стандартов от вендоров предлагалось что-то странное: жесткие коллизии, мягкие, газообразные… Это аналогично 4D, 5D, 6D, 7D. Проблема в том, что пока не посмотришь, что это значит, не поймешь, о чем речь. В результате - недопонимание и проблемы в коммуникации. Поразмыслив мозгами, давайте попробуем переработать эту концепцию, и подумаем, как навести порядок в коллизиях и проверках. 🔍 В приложенном ниже файле я предложил структуру типов коллизий/дефектов, выявляемых в результате верификации и валидации. Коллизии представлены шире, чем только геометрические. На истину не претендую, просто предложение. 🔹 При верификации выявляются дефекты в синтаксисе и семантике набора данных (файла IFC, XML-документа и т.д.). Например, в IFC-файле обнаружен GUID, начинающий с буквы, хотя по правилам в IFC он должен начинаться с цифры. 🔹 При валидации проверяем данные на различные семантические требования (в том числе высокого уровня: нормативные требования). Это лишь набросок, но такое деление добавит системности и в перспективе не позволит упустить ни одну категорию проверок и будет основой для дальнейшей автоматизации. 👥 @IFC_ru 👥 @IFC_club

Всё про IFC pinned «СОДЕРЖАНИЕ 2026 (обновляется) 1. Коллизии. Новый взгляд? + иерархия коллизий 2. Коллизии. Новый взгляд? Дополнение. 3. 4. 5. 6. 7. Подкасты "BIM-среда" на Youtube 📹 | Rutube 📺 👥 @IFC_ru 👥 @IFC_club»

СОДЕРЖАНИЕ 2026 (обновляется) 1. Коллизии. Новый взгляд? + иерархия коллизий 2. Коллизии. Новый взгляд? Дополнение. 3. 4. 5. 6. 7. Подкасты "BIM-среда" на Youtube 📹 | Rutube 📺 👥 @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

Предновогодний прогон всех постов канала через ИИ (+статистика от 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

Перевод реестра требований из человекочитаемой формы в машинно-интрепретируемую - задача непростая. Самое главное здесь - выстроить четкий фундамент, иначе это будет работа в стол. На прошедшем XI BIM-Форуме команда Института системного программирования РАН представила технологический стек, меняющий подход к цифровой нормативной базе. Их цель - это полная автоматизация цепочки: НОРМАТИВ (текст) ➡️ OWL-ОНТОЛОГИЯ ➡️ SPARQL/SWRL-ПРАВИЛА ➡️ IDS++ ➡️ АВТОПРОВЕРКА IFC Текст нормативов предлагается сначала переводить в виде OWL-онтологии (машинопонятный "словарь"). Далее с помощью SPARQL (язык запросов) и SWRL (язык логических правил) они трансформируются в спецификации IDS/IDS++ для проверки IFC-моделей. Таким образом, от пункта норматива появляется сквозная прослеживаемость к правилу SWRL, его формализованному представлению в IDS++ и далее (после валидации) к замечанию в BCF. Важно, что система будет проводить семантическую проверку, то есть "понимать" и обращаться не только к атрибутам модели, но и контексту, отношениям и геометрии. Это не ещё один плагин, а создание формальных знаний для строительной отрасли. Фундаментальный подход, где конечным продуктом являются готовые стандартизированные IDS-файлы для повседневной практической проверки данных в IFC. 👥 @IFC_ru 👥 @IFC_club

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

В Москве проходит ежегодный форум РосТИМ 2025 от Аскон. Неожиданно для себя получил награду за «популяризацию правильных подходов» по работе с открытыми форматами. Друзья! Искренне радует, что нашу деятельность оценивают и разработчики ПО. А значит, надеюсь, мы движемся в нужном направлении. Этот канал - это только часть нашей деятельности, здесь всё на энтузиазме. И хотя постов стало чуть меньше (в связи с загрузкой под конец года), но я считаю, что лучше писать что-то интересное и по делу, чем просто написать что-нибудь о BIM. 👥 @IFC_ru 👥 @IFC_club

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