Вчерашний ликбез по IDS от Тимура Шарафутдинова выдался максимально продуктивным. Если вам интересна тема машиночитаемых требований, настоятельно рекомендуем к просмотру.

Хочется отметить еще несколько моментов.

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

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

⬜️ Привязка IDS к IFC и его открытость дает бОльшее преимущество перед остальными разработками, которые к IFC не привязаны, а заточены под какое-то конкретное ПО или сервис.
В случае же связки IDS+IFC мы можем быть более уверены, что машинная проверка сработает корректно, так как нам известно не только как формализована проверка, но и как структурированы данные, которые мы проверяем.

#IDS

👥 @ifc_ru
👥 @ifc_club

1 февраля представители отечественных BIM-решений Tangl, IYNO и Signal расскажут о результатах их совместной работы по переводу системы классификации Uniformat 2015 на русский язык.

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

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

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

- IfcClassificationReference - служит для записи кода и его описания согласно применяемой системе классификации.

#База

👥 @ifc_ru
👥 @ifc_club

Погружаемся в IFC-аннотации

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

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

https://telegra.ph/Annotacii-v-IFC-01-31

#Углубленка

👥 @ifc_ru
👥 @ifc_club

🌐 IFC - Конец Вавилонской башни - 1994 (русский перевод)

Этому раритетному короткому ролику 30 лет. Но он до сих пор не потерял актуальности.

В фильме простым языком рассказывается, как всё начиналось и с какой целью компании-основатели IAI (будущий buildingSMART) начали разрабатывать стандарт IFC.

Приятного просмотра!

#База

👥 @IFC_ru
👥 @IFC_club

Традиционный подкаст "BIM-среда" в IFC Клубе!

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

🔊 Тема: "IFC на всем жизненном цикле объекта"

Спикер:
👤 Владислав Золотов, старший научный сотрудник Института системного программирования РАН им. В.П. Иванникова

Поговорим о том:
🛑 как выглядит IFC глазами программиста и как с ним можно работать;
🛑 какие данные можно хранить в IFC;
🛑 возможно ли применение IFC на различных этапах жизненного цикла.

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

👥 @IFC_ru
👥 @IFC_club

Свойства в IFC

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

В стандарте IFC история с характеристиками объектов представлена несколько иначе. Существуют три вида характеристик:

🛑 атрибут (attribute) - это "встроенные" характеристики объекта (сущности), такие как GlobalID, Name, Tag, PredefinedType и т.д. Их количество строго ограничено схемой IFC.

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

🛑 количественный показатель (quantity) - здесь записываются показатели, индивидуальные для каждого элемента и вычисляемые в САПР, например, длина, площадь, объем и так далее. Также группируются в наборы (Qset’ы).

Атрибуты в свою очередь подразделяются на:
🛑 прямые (явные) атрибуты (direct attribute) - их мы обычно видим в просмотрщике в диспетчере свойств вместе со всеми остальными свойствами. В структуре файла IFC для них всегда отведено место;
🛑 обратные (инверсные) атрибуты (inverse attribute) - эти атрибуты в файл IFC не выгружаются, на них пока останавливаться не будем;
🛑 производные (вычисляемые) атрибуты (derived attribute) - вычисляются по значениям из других атрибутов и зависимые от них.

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

https://bimcorner.com/properties-in-ifc/

#База

👥 @IFC_ru
👥 @IFC_club

По просьбам трудящихся подключаем комментарии 📝
P.S. Предыдущие посты откомментировать нельзя

Спешим сообщить, что у нас появился канал на 📹Youtube!

Теперь все подкасты можно посмотреть в плейлисте "BIM-среда".

#1= Поворот в сторону IFC? (А. Высоцкий, О. Коршунова)
#2= Open Design Alliance - от DWG до IFC (А. Боровиков)
#3= Открытые ТИМ-стандарты в теории и на практике (В.А. Семёнов, часть 1)
#4= Открытые ТИМ-стандарты в теории и на практике (В.А. Семёнов, часть 2)
#5= bSDD - что это и зачем? (Илья Усов)
#6= Раскрывая возможности IFC (Д. Чилин, В. Хоцанович)
#7= IFC на всём жизненном цикле объекта (В. Золотов)

Подписывайтесь, чтобы ничего не пропустить!

👥 @IFC_ru
👥 @IFC_club

🌐 IFC: панацея или суррогат?

С таким заголовком вышел журнал "Информационное моделирование" (от компании CSoft) с двумя статьями, посвященными плюсам и минусам применения IFC.

🆙 Начнем с аргументов "ЗА" от заместителя генерального директора Renga Software Максима Нечипоренко. Выделим ключевые моменты из его статьи:

✅открытость спецификации IFC;
✅огромная история и проработанность;
✅сформированное сообщество в лице нескольких сотен ПО;
✅возможность раcширения схемы IFC;
✅закреплен в качестве национального стандарта (ГОСТ Р 10.0.02-2019/ИСО 16739-1:2018);
✅гибкость и разные способы настройки модельных представлений (MVD);
✅вариативность (возможность представления в различных нотациях)

🆙 Аргументы "ПРОТИВ" готовил Александр Волков, директор ГК CSoft Дальний Восток. Главные недостатки применения IFC по его мнению:

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

P.S. Стоит отметить, что пункты "ПРОТИВ" следует прокомментировать отдельно, так как каждый из них по большому счету является нерешённым вопросом, сложностью.
Комментарии последуют далее 👉

#Мифология

Прокомментируем перечисленные выше недостатки IFC.

⬜️ Сложности обмена данными из-за использования разработчиками разных графических ядер для своих приложений.

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

⬜️ Сложности с прямым редактированием модели в IFC.

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

Но если и говорить о "нативном" и редактируемом IFC, то это возможно и этому есть практические примеры. Правда до недавнего времени этой задачей мало кто из разработчиков занимался. Однако сегодня существует ряд решений, поддерживающих редактирование IFC файлов, например 7d моделер, ACCA usBIM.editor, BlenderBIM, некоторые утилиты от BIMVision и другие.
Кроме того, в России разрабатываются два независимых друг от друга IT-стартапа по генерации моделей зданий в IFC.

#Мифология

Продолжение:

⬜️ Зависимость новых версий IFC от финансирования со стороны крупных игроков строительного рынка.

Комментарий:
Любая серьезная разработка зависит от финансирования. На голом энтузиазме они не делаются. И разработчики САПР поступают точно так же.

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

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

Конечно, есть альтернатива не вкладываться в развитие IFC, а подчиниться монополистам вроде Autodesk с его закрытыми форматами, и тогда никаких открытых стандартов не будет в принципе. Но у такого монопольного подхода совсем другие риски.

⬜️ Санкционные ограничения не дают возможности использовать будущие редакции стандарта IFC в юридическом плане.

Комментарий:
1) IFC - открытой стандарт. Он описывается на языке EXPRESS, закрепленном стандартами ISO 10303, которые переведены на русский язык в качестве национальных стандартов ГОСТ Р.

2) Принятие актуальной версии IFC4x3 в качестве стандарта ISO 16739, планируемое в апреле 2024 года, позволит применять его без каких-либо юридических препятствий и угроз национальной безопасности. Более того, это только поспособствует утверждению его национальным стандартом.

#Мифология

Завершение:

⬜️ Использование IFC не решает проблемы применения пиратского ПО;

Комментарий:
Встречный вопрос: а какой формат это решает? Это проблема из другой плоскости и решение ее не связано с форматами данных. По этой логике XML-формат предоставления смет (.gge) способствует пиратству сметных программ?
Наоборот, открытые форматы позволяют как развиваться бесплатным openSource проектам, так и договариваться различным разработчикам между собой (пример, объединение АРСИТИМ с форматом. TIMML).

⬜️ В IFC не учтена национальная специфика строительной отрасли.

Комментарий:
Во-первых, в статье не приводится примера, а в каком формате решены все вопросы национальной специфики, и в чем она заключается.

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

И в завершение отметим, что за 30 лет существования IFC у представителей отечественной стройотрасли и разработчиков САПР, как и у всего мира, всегда была возможность повлиять на развитие IFC и внести свои предложения. На наш взгляд, это лишь вопрос IT-зрелости как отдельных организаций, так и отечественной отрасли в целом.

#Мифология

👥 @IFC_ru
👥 @IFC_club

Что означают цвета в описании классов IFC

В технической спецификации стандарта IFC различные сущности помечены разными цветами. Расшифруем, что они значат:

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

🛑Серым обозначается "верхнеуровневая" абстрактная сущность, на базе которой экземпляры не могут быть созданы.

🛑Красным - классы, которые будут удалены в следующих версиях схемы IFC и больше не будут использоваться.

Изменяются ли эти классы от версии к версии схемы?

Да, изменяются, так как со временем приходит новое понимание классификационной иерархии.

Пример: В схеме IFC4 сущность IfcBuildingElement, обобщающий строительные классы здания, является абстрактным. Но в схеме IFC4x3 он переименован в IfcBuiltElement и стал определенным. Теперь этот строительный класс относится не только к зданиям. И он может быть назначен элементам, которые не конкретизированы в классификационной системе IFC.

#База

👥 @IFC_ru
👥 @IFC_club

Как описываются “пустоты” в IFC?

Зачастую в САПР есть довольно ограниченный инструментарий для создания элементов, отвечающих за создание пространств, зон, помещений, отверстий. Так, например, проектировщики чаще всего моделируют отверстия с помощью «окон». А для группировки помещений необходимо добавлять к ним свойства, определяющие принадлежность к той или иной группе, что является достаточно примитивным способом.

В IFC для таких задач выделены отдельные сущности. (см. шпаргалку).

Можно условно выделить два типа таких элементов:

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

🛑 "вырезающие", то есть зависимые от физических элементов и вычитающие их объем.

Для группировки "самостоятельных" пространств предусмотрена отдельная сущность IfcZone, которая не содержит собственной геометрии. Эта сущность, например, хорошо подойдет для объединения помещений в квартиры.

#База