how-to-ifc_titel.PNG

Будущее открыто

Ввиду того, что, вероятно, никогда не будет предложено целостного решения, с помощью которого можно было бы отобразить все виды процессов от начального этапа разработки проекта до управления зданием, необходимы открытые интерфейсы. Идея цифрового отображения всего жизненного цикла здания может работать только как успешное взаимодействие нескольких программных сред. Видение этой проблемы в прошлом привело к тому, что основные производители программных решений с поддержкой BIM (например, CAD, AVA и CAFM) открылись для непроприетарных технологий, таких как IFC и BCF. Несомненно, это важная основа для принципиальной осуществимости открытых процессов. Однако реальность показывает, что практическая реализация необходимых вариантов использования во многих местах всё ещё является картиной будущего.

Это как раз то, что должно измениться в ближайшие годы. Там, где сегодня изолированные приложения, такие как „little BIM“ или „closed BIM“ воспринимаются как самые передовые технологии, в будущем всё это будет указывать на „big open BIM“, междисциплинарное сотрудничество, основанное на нейтральных форматах обмена. Такой вывод напрашивается, с одной стороны, ввиду конкретных действий известных производителей программного обеспечения, например, совсем недавно компания Autodesk присоединилась к Open Design Alliance. С другой стороны, в руководствах по обмену информацией в проектах BIM всё чаще ссылаются на IFC в соответствии с DIN EN ISO 16739 и BCF. В качестве примеров здесь можно привести проекты VDI 2552 лист 9 (системы классификации) и VDI 2552 лист 11.2 (требования к обмену информацией: проектирование проёмов). Даже DIN EN ISO 19650, хоть и написан в значительной степени нейтрально в отношении формата, явно даёт понять читателю, на какой основе рекомендуется реализация содержащихся концепций.

Эта статья ставит своей задачей подготовить почву для внедрения конкретных решений. Она призвана предоставить опытным пользователям Revit информацию о том, как безопасное использование IFC и связанных с ним технологий может найти своё отражение в процессах проектирования инженерных систем уже сегодня. Помимо объяснения некоторых важных основ, мы даём конкретные рекомендации по внедрению рабочих процессов проектирования инженерных систем. На примере liNear Solutions и Autodesk Revit мы рассматриваем уровень развития техники и предоставляем подробную информацию о принципе работы соответствующих интерфейсов IFC и взаимодействии платформ.

Варианты использования BIM и определение модельного вида
Если вы получаете файл IFC от другого участника проекта или предоставляете свой собственный рабочий статус, то сначала следует уточнить, для какой цели служит эта передача информации. В лучшем случае конкретные требования к информации определяются в плане выполнения BIM-проекта, чтобы поставщик информации мог передать получателю именно ту информацию, которая требуется для предполагаемого варианта использования. Если получателю предоставляется только подмножество модели, то в таком случае говорят об определении модельного вида (Model View Definition; MVD). В отличие от простых фильтров вида, известных из CAD-приложений, MVD позволяет не только генерировать вид модели, но и главным образом определять тип и объём экспортируемой геометрической и буквенно-цифровой информации. Например, описание геометрии элемента может быть преобразовано в явную форму (граничные плоские поверхности) или набор экспортируемых атрибутов может быть ограничен требуемой и уже сохранённой информацией. Таким образом, если говорят, что для определённого варианта использования ожидают IFC, то на самом деле имеется в виду MVD.

В ходе разработки IFC было выпущено несколько версий MVD, например, известный IFC 2x3 Coordination View 2.0, который определяет подмножество схемы IFC 2x3, необходимое для целей координации. В большинстве сред также возможен экспорт с фильтрами исходных моделей и использование дополнительных параметров экспорта, которые позволяют в ограниченной форме определять свои собственные MVD. Кроме того, с помощью (ручной) классификации пользователь может точно настроить классы и типы IFC, а также сопоставление наборов атрибутов конкретного типа, если используемая среда разработки не может быть отображена на используемой схеме IFC. Однако этот шаг представляет собой проблему для большинства пользователей из-за сложности интерфейсов. Несмотря на то, что для охвата максимально возможного диапазона вариантов использования необходима определённая мощь интерфейсов, на практике шаги ввода и вывода сводятся к использованию ранее определённых профилей конфигурации. В конечном счёте, это то же самое, что и с шаблоном проекта: кто-то в компании должен определить, как он должен выглядеть. Остальные сотрудники просто используют этот шаблон. Что касается работы с архитектурными моделями, то уже существуют согласования различных авторских платформ (например, AddIn „IFC Model Exchange“ для упрощённого обмена между Archicad и Revit). Однако, что касается проектирования инженерных систем, то лишь небольшая часть пользователей понимают интерфейс IFC для Revit на уровне, необходимом для реализации открытых процессов проектирования.

В чём заключается сложность использования рабочих процессов на основе ifc при проектировании инженерных систем?
Если вам нужно отобразить семантическую или последовательно классифицированную модель здания, IFC предлагает сотни стандартизированных классов, типов и наборов свойств, с помощью которых вы можете это реализовать почти без каких-либо противоречий. Среда разработки, такая как Revit, изначально не имеет такого требования. Здесь достаточно, чтобы элементы были разделены на категории в зависимости от их общего назначения и режима редактирования (например, стены, потолки, комплектующие для труб, компоненты механического оборудования и т. д.). Именно обстоятельство неоднозначной машинной переводимости типов IFC и их параметров в средах разработки требует повышенного внимания как при использовании IFC в качестве конструкторской подложки, так и при экспорте IFC для передачи.

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

Координация моделей инженерных систем посредством IFC
Прежде чем мы объясним, как можно сгенерировать собственные выходные данные IFC, давайте сначала рассмотрим два распространённых варианта использования, когда проектировщик инженерных систем получает IFC в качестве основы для проектирования.

Координация разных разделов проекта
Если инженерное бюро не проектирует все разделы в одном и том же ПО или если в проекте задействованы разные проектировщики инженерных систем, то может случиться так, что IFC будет выступать в качестве общего знаменателя для обеспечения координации. В этом случае пользователи Revit оказываются в ситуации, когда им приходится ссылаться на статус плана другого инженерного раздела в своём собственном проекте. Для этого предлагается связать файл IFC. Во время этого процесса IFC-интерфейс Revit создаёт в фоновом режиме проект Revit с расширением „.ifc.rvt“. Наряду с этим создаётся файл журнала для локализации ошибок, а также файл общих параметров с расширением „.ifc.sharedparameters.txt“, который можно настроить в Revit для ознакомления с определениями общих параметров в проекте.

В нашем примере мы рассматриваем систему отопления, которая была спроектирована с помощью LINEAR Design 3D Pipe&Power в AutoCAD и экспортирована как IFC 2x3 Coordination View 2.0. Сразу после связывания в Revit результат выглядит неутешительно. Там, где в окне просмотра IFC системы трубопроводов были выделены яркими цветами (рисунок 2), после связывания мы видим полностью окрашенную в чёрный цвет сеть (рисунок 3). Однако эта чёрная окраска является просто проблемой отображения. Если рассматривать отдельные элементы вблизи, то обнаруживается, что эта окраска является результатом явной генерации геометрии рёбер. Сейчас в Revit нет возможности скрыть линии сетки импортированных объектов с помощью центрального механизма. Однако, используя фильтры, можно сделать так, чтобы Revit окрашивал системы в соответствии с вашей классификацией систем.

Для этого сначала назначьте упомянутый ранее файл определения параметров с расширением „.ifc.sharedparameters.txt“ в качестве файла общих параметров. После этого содержащийся в нём параметр „IfcSystem“ будет определяться как параметр экземпляра для соответствующих категорий. Классификация по категориям Revit, а также конкретная системная идентификация элемента могут быть выполнены путём проверки свойств объекта. В данном случае системы с обозначениями „Подающая магистраль“ и „Обратная магистраль“ должны быть отфильтрованы. Для этого в переопределениях видов Revit создаются фильтры на основе правил для категорий труб. В качестве условия вы указываете, что атрибут „IfcSystem“ должен соответствовать значению „Подающая магистраль“ или „Обратная магистраль“. Вы также можете переопределить цвет линии для этих фильтров по своему усмотрению.

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


Очень кратко

Используйте автоматически сгенерированный текстовый файл с расширением „.ifc.sharedparameters.txt“ в качестве основы для создания фильтров вида.
1. Сопоставьте подходящий параметр фильтра с соответствующей категорией, например:

ПараметрЗначение
IfcSystemСистемная принадлежность („Подающая магистраль“, „Вытяжной воздух“ и т. д.)
IfcExportAsКлассификация IFC („IfcСегментТрубы“, „IfcБойлер“, „IfcРезервуар“ и т. д.)
IfcSpatialContainerЭлемент более высокого порядка (например, „Первый этаж“)

 

2. Установите отображение вашей связки на настройку „в соответствии с видом базовых элементов“.
3. Создайте фильтры на основе правил для управления видимостью и отображением содержимого классифицированной модели.


Архитектура IFC в качестве подложки
Другой вариант использования, в котором модель IFC используется в качестве подложки, – это разработка модели инженерных систем на основе существующей архитектуры. В этом случае архитектурный чертёж служит нескольким целям: с одной стороны, базовая модель создаёт систему координат для моделирования инженерных систем и последующих координационных задач, таких как проектирование проёмов. С другой стороны, архитектура служит границей помещения для пространств, которые необходимы для определения граничных условий для расчёта параметров.

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


Informationen
Для большинства вариантов использования на основе архитектуры IFC достаточно, чтобы модель содержала все элементы, ограничивающие помещение, с соответствующей классификацией (например, IfcWalls), а также были экспортированы проёмы для окон (IfcWindow) и дверей (IfcDoor). Если подложка IFC также включает объекты помещения (IfcSpace), то на основе архитектуры IFC, используя решение LINEAR, можно легко генерировать пространства и передавать данные из архитектурной модели. Таким образом, значения потребного расхода для конкретного помещения (например, объёмы воздуха, тепловые нагрузки и т. д.), установленные из проектных спецификаций или подробных расчётов нагрузки, могут быть записаны в соответствующие объекты помещения (для более детальной информации см. LINEAR aktuell 1-2020, стр. 22 и далее).


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

Чтобы семантическая информация, упомянутая выше, не стала жертвой процесса импорта, важно правильно настроить таблицу назначений импорта IFC. Эта таблица сопоставляет классы и типы IFC с соответствующими категориями Revit, поэтому она служит справочником для функции импорта. Несмотря на то, что упомянутая таблица заполняется значимыми предложениями при установке Revit, в зависимости от используемой архитектурной платформы и параметров экспорта может потребоваться добавить записи или изменить назначения. Кроме того, содержимое модели, которое не требуется, можно игнорировать для импорта, указав „DontImport“ вместо категории Revit.

После связывания архитектурной подложки IFC можно заметить, что оконные проёмы, которые фактически являются полой формой, в связке показаны как объекты категории „Обобщённая модель“. Если вы откроете свойства вида связки, вы обнаружите, что эти проёмы сохраняются процедурой импорта в подкатегории „IfcOpeningElement“, которая, к сожалению, не отображается в проекте более высокого уровня (рисунок 6).

Существует два способа скрыть проёмы. Во-первых, вы можете заменить вид связки пользовательскими настройками. Во-вторых, вы можете использовать вид базовых элементов и создать фильтр видимости, как показано выше, который фильтрует объекты в категории „Обобщённая модель“ со значением „IfcOpeningElement“ для атрибута классификации „IfcExportAs“.

Для создания MEP-пространства на основе связки IFC можно использовать функциональные возможности пространств из liNear Desktop. Он определяет контуры помещения на основе элементов IfcSpace и передаёт такие параметры, как имя/номер и любые атрибуты IFC, в соответствующие пространства. Дополнительные технические граничные условия могут быть введены через диалоговые окна свойств или перенесены из экспликации помещений в модель инженерных систем с помощью интерфейса LINEAR Excel.

Экспорт моделей инженерных систем в ifc
Вывод файла IFC может выполняться по разным причинам. Например, с целью документирования, для координации модели, визуализации задач или передачи данных на различных этапах процесса (например, обмен данными по требуемой площади для инженерных систем, проектирование проёмов, передача генеральному подрядчику, смета или определение объёма работ). По этой причине важно, чтобы требования к содержанию и качеству были согласованы заранее. Интерфейс экспорта IFC платформы Revit предлагает набор функций, которые не сразу очевидны и понятны пользователям. Ниже мы рассмотрим три важных аспекта: классификации, наборы свойств и параметры экспорта.


СОВЕТ

Используйте спецификации для быстрой проверки созданных пространств.

  • Переносите данные помещения с помощью liNear-Desktop из помещений IFC в соответствующие MEP-пространства.
  • Создавайте спецификации с соответствующими графами (например, имя, номер, площадь).
  • Используйте вычисляемые столбцы и условное форматирование для визуализации отклонений.

Пример: процент отклонения площадей помещений между пространствами и помещениями.


Каскад классификации
Revit по умолчанию предлагает различные механизмы для классификации элементов. Самая простая форма классификации – это категории, по которым классифицируются элементы. Этот довольно прагматичный способ различения на самом деле предназначен только для среды разработки, поскольку, например, окно ведёт себя иначе, чем аксессуар для труб. Эта классификация очень приблизительна, и она исчерпывает все свои возможности, когда дело доходит до сопоставления с более чётким членением, в данном случае для правильного экспорта IFC.

Вся сложность обнаруживается, если взглянуть на таблицу классов экспорта IFC в Revit, в которой категории Revit очень грубо сопоставлены с классами IFC. Категория Revit „Механическое оборудование“, которая чрезвычайно важна для инженеров-проектировщиков, по умолчанию преобразовывается здесь в „IfcBuildingElementProxy“, IFC-эквивалент „Обобщённой модели“. Это означает, что у важного класса объектов отсутствует конкретное семантическое назначение. По-правильному, компоненты механического оборудования должны быть сопоставлены с большим подмножеством класса более высокого уровня „IfcDistributionElement“ (инженерно-технические элементы), который включает, среди прочего, различные типы генераторов, накопителей, потребителей и регуляторов.

Поэтому, чтобы семантически обогатить модель экспорта, рекомендуется провести более точную классификацию. Имя параметра, зарезервированное для этого, – „IfcExportAs“. Более новые версии интерфейсов IFC по-прежнему понимают определение „IfcExportAs[Type]“, что позволяет пользователю классифицировать как на уровне экземпляра, так и на уровне типа. В любом случае необходимо убедиться, что каждый из этих параметров встречается в проекте только один раз. Если используются семейства из разных источников, может случиться так, что эти параметры уже предустановлены, но отличаются своим уникальным идентификатором (GUID). На фоне того, что IFC постоянно совершенствуется, такая предварительная классификация должна быть проверена пользователем, поскольку атрибут „IfcExportAs“ не может рассматриваться как основной вариант IFC, и иногда могут быть добавлены новые классы или удалены устаревшие классы.

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

Здесь в каскаде используется первый непустой параметр. По историческим причинам программа экспорта также обрабатывает возможные варианты написания строчными и прописными буквами названий параметров. Таким образом, один параметр может пониматься как „IFCExportAs“ или „IFCEXPORTAS“.

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

Наборы свойств
В дополнение к классификации решающее значение для точной передачи информации имеют наборы свойств. Разбивка атрибутов по наборам свойств (англ. property sets, часто используют слово „Pset“ для краткости) позволяет целенаправленно контролировать, какая информация должна передаваться в итоговый файл IFC, а какая нет. При этом вы можете структурировать свои собственные атрибуты или экспортировать стандартизованные наборы свойств, определённые, например, в рамках ISO 16739-1: 2018 или buildingSMART Data Dictionary (bsDD). Важным условием для этого является уже проведённая классификация ваших элементов.

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

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

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

Базисные количества
Эта настройка экспортирует наборы количеств (англ. quantity take off, сокращённо „Qto“), которые включают, например, такие свойства, как наружные размеры. На данный момент, кажется, они не были реализованы для элементов, относящихся к инженерным системам (например, Qto_SpaceHeaterBaseQuantities).

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

ifc

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

Для этого мы просто определяем параметр экземпляра „IfcExportAs“ для категории спецификаций. Он имеет специальное значение „DontExport“, которое гарантирует, что родительская спецификация не будет экспортирована, даже если мы активировали опцию экспорта спецификаций PSet. Это значение также подходит для фильтрации отображения в Диспетчере проекта. Таким образом, мы можем скрыть спецификации согласно принципу WYSIWYG, которые не имеют отношения к предстоящему экспорту.

Вы также можете использовать функцию „да/нет“ в глобальных параметрах, чтобы установить соответствующий параметр на значение „DontExport“ в случае нескольких списков, как показано в примере на рисунке 13.
Этот механизм также можно использовать, например, для реализации требования к задаваемой глубине потребности в информации (Level of Information, LoI) для экспорта. Это означает, что проектировщик может предоставить только те данные, которые требуются на текущем этапе в соответствии с планом выполнения BIM-проекта. Например, для целей тендера можно не предоставлять наборы свойств, которые содержат информацию о производителе. Позже эта информация может быть включена в экспорт IFC посредством увеличения глубины потребности в информации.


Очень кратко

Улучшите свой экспорт IFC, творчески используя функции Revit:

  • Фильтруйте элементы с помощью классификации экспорта IFC для целевого создания наборов свойств.
  • Организуйте списки свойств, задав фильтры и параметры структурирования в Диспетчере проекта.
  • Целенаправленно управляйте информацией, которую вы выводите, через классификацию IFC-экспорта спецификаций.
  • Привяжите классификацию экспорта IFC к глобальным параметрам для удобной активации/деактивации нескольких наборов свойств.

 

Настройки экспорта
Eсли необходимо экспортировать только определённые фрагменты модели, рекомендуется создать вид для экспорта и активировать соответствующую настройку экспорта IFC. Таким образом, экспортируются только те элементы, которые видны на этом виде. Тот же самый вид следует использовать для создания геометрии, что управляется с помощью другой опции. Также рекомендуется сохранить идентификаторы IFC (GUID) в параметре элемента после экспорта, поскольку таким образом документируется двунаправленное соединение между объектами IFC и соответствующими элементами Revit.

Ещё один важный вопрос касается правильного определения модельного вида (MVD), который в настройках Revit обозначается как версия IFC. В настоящее время Revit может поддерживать несколько версий схемы IFC, из которых наиболее значимыми являются IFC 2x3 и IFC 4.

Сделать выбор между этими двумя версиями не просто, так как имеются веские аргументы в пользу обеих. В то время как IFC 2x3 находит широкое практическое применение и имеет полностью сертифицированные интерфейсы, IFC 4 содержит несколько полезных нововведений. Так, например, вводятся типы „Provision for Space“ (временное пространство) и „Provision for Void“ (временное пустое место), которые идеально подходят для координационных целей между разделами.

Помимо введения новых полезных классов, типов и других улучшений, также были значительно улучшены возможности геометрического представления элементов. На рисунке выше показаны результаты экспорта двух уровней детализации геометрии простого резервуара с использованием различных MVD. В то время как результаты „Coordination View 2.0“ и „Reference View“ генерируют явную геометрию на основе плоских многоугольников, „Design Transfer View“ позволяет отображать днища резервуаров, смоделированные в Revit, практически без потерь.

Триангуляция этих тел вращения и цилиндрической оболочки резервуаров выполняется только в целях отображения в программе просмотра IFC (здесь: Open IFC Viewer 21.10). В то время как неявное представление при высокой геометрической точности производит сравнительно небольшой объём данных, интерпретация на приёмной стороне связана со значительно большими усилиями. По этой причине, а также ввиду ещё не завершённой сертификации интерфейсов Revit, использование предпочтительного вида „Design Transfer View“ в продуктивных средах подходит только в том случае, если совместимость между „платформой-генератором“ и „платформой-потребителем“ была тщательно проверена.

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

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

liNear будет сопровождать вас на этом пути, предоставляя множество новых функций для программного решения Desktop. Уже сегодня многое возможно. Поначалу это может быть трудоёмко, но нет необходимости в одномоментном достижении 100 %. Важно сегодня установить правильный курс, чтобы в будущем не упустить цифровые коммуникации.

Кристиан Валуга


 

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