Понимание схемы IFC: сущности, наборы свойств и MVD

Понимание схемы IFC: сущности, наборы свойств и MVD

IFC (Industry Foundation Classes) — открытый стандарт ISO для обмена строительными данными. На практике с ним сталкиваются каждый раз, когда модель переходит между программами или загружается в облачный просмотрщик. Чтобы понять, почему какие-то данные теряются при экспорте или не отображаются в интерфейсе, нужно разобраться со структурой схемы.

Что такое схема IFC

IFC описывается на языке EXPRESS (ISO 10303-11) и публикуется как текстовый файл .ifc или бинарный .ifczip. Актуальные версии — IFC2x3 и IFC4. Схема задаёт:

• типы данных — примитивы, перечисления, выборки;
• сущности — классы объектов со своими атрибутами;
• правила — WHERE-клаузы, которые ограничивают допустимые значения.

Любой объект в файле — это экземпляр конкретной сущности схемы.

Иерархия сущностей

Все сущности IFC выстроены в единое дерево наследования. На вершине — абстрактный IfcRoot, от него наследуют:

• IfcObjectDefinition → строительные объекты (IfcWall, IfcBeam, IfcSpace и т. д.);
• IfcRelationship → отношения между объектами (принадлежность, агрегация, классификация);
• IfcPropertyDefinition → определения свойств.

Каждый объект здания — конкретный подкласс. Например, стена — это IfcWall, а её тип — IfcWallType. Отношение «стена принадлежит этажу» кодируется экземпляром IfcRelContainedInSpatialStructure.

Понимание иерархии важно при фильтрации: запрос «все несущие стены на 3-м этаже» — это обход нескольких уровней отношений, а не простой поиск по имени.

Атрибуты против свойств

Начинающие часто путают эти два понятия.

Атрибуты — поля, жёстко заданные схемой для каждой сущности. Например, IfcRoot.GlobalId, IfcElement.Tag. Их набор фиксирован и одинаков для всех файлов.

Свойства — расширяемый механизм. Они хранятся в объектах IfcProperty и группируются в наборы свойств (IfcPropertySet). Связь с элементом устанавливается через IfcRelDefinesByProperties.

Это означает, что один и тот же IfcWall может иметь стандартный набор Pset_WallCommon с огнестойкостью и теплопроводностью, а рядом — пользовательский набор MyCompany_WallData с внутренними кодами.

Стандартные наборы свойств (Pset)

buildingSMART публикует библиотеку стандартных Pset для каждого класса объектов. Несколько примеров:

| Набор | Применяется к | Ключевые свойства | |---|---|---| | Pset_WallCommon | IfcWall | FireRating, ThermalTransmittance, LoadBearing | | Pset_SlabCommon | IfcSlab | PitchAngle, IsExternal | | Pset_SpaceCommon | IfcSpace | GrossPlannedArea, IsExternal | | Pset_DoorCommon | IfcDoor | FireRating, AcousticRating |

Стандартные наборы нужны, чтобы разные участники проекта и разные программы могли читать одни и те же свойства без предварительных договорённостей.

Пользовательские наборы свойств

Когда стандартных Pset недостаточно, проектировщики создают собственные. Правила простые:

• Имя набора не должно начинаться с Pset_ — этот префикс зарезервирован за buildingSMART.
• Рекомендуется использовать префикс организации или проекта: ACME_StructuralData.
• Каждое свойство внутри набора — экземпляр IfcPropertySingleValue, IfcPropertyBoundedValue или другого подкласса IfcProperty.

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

Что такое MVD

Model View Definition (MVD) — это формальный подраздел схемы IFC, который определяет минимально необходимый набор сущностей и свойств для конкретного сценария обмена данными.

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

Распространённые MVD

• Coordination View — геометрия и пространственная структура для координации;
• Reference View — упрощённая геометрия для просмотра без редактирования;
• Design Transfer View — более полный обмен для передачи авторской модели;
• COBie — данные для эксплуатации здания (без геометрии).

Каждая программа заявляет поддержку конкретных MVD в своём сертификате buildingSMART. Если экспортёр и импортёр поддерживают один MVD — данные передаются предсказуемо.

Как схема IFC влияет на работу с облачным просмотрщиком

Когда IFC-файл загружается в Voxa, сервер разбирает схему и строит внутреннюю модель объектов. Это влияет на несколько вещей:

• Дерево объектов формируется по иерархии IfcSite → IfcBuilding → IfcBuildingStorey → IfcSpace/IfcElement.
• Панель свойств показывает атрибуты сущности и все связанные Pset — как стандартные, так и пользовательские.
• Фильтры и поиск работают по значениям свойств: можно выбрать все элементы с Pset_WallCommon.LoadBearing = TRUE.
• Геометрия берётся из IfcShapeRepresentation; тип представления (тело, кривая, точка) определяет, как элемент отрисовывается.

Если модель экспортирована с неправильным MVD или с нестандартными именами Pset, некоторые свойства могут не попасть в нужные поля — это не ошибка просмотрщика, а следствие несоответствия схемы.

Практические рекомендации

• Согласуйте MVD заранее. Перед экспортом убедитесь, что все участники используют один и тот же MVD. Для координации — Coordination View или Reference View.
• Используйте стандартные Pset там, где они есть. Не изобретайте MyFire вместо Pset_WallCommon.FireRating.
• Проверяйте GlobalId. Каждый элемент должен иметь уникальный GUID — он используется для связывания данных между пересмотрами модели.
• Не дублируйте данные в имени и свойствах. Если значение уже есть в атрибуте Name, не нужно повторять его в Pset: это засоряет модель.
• Тестируйте round-trip. Экспортируйте модель, загрузите обратно в исходную программу и сравните свойства — это быстрый способ выявить потери при экспорте.

Итог

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